devopsy.kinsta.cloud

Category: Enterprise DevOps

  • 4 Steps to More Agile Operations

    4 Steps to More Agile Operations

    After over a year of business disruptions, modern enterprises have realized that speed and agility are the only way forward. In fact, according to Gartner’s Top Strategic Technology Trends for 2021 eBook, “Organizations that don’t focus on efficiency, efficacy, and business agility will be left behind.”

    In order to stay future-ready, organizations across all industries are moving to adopt an operating model that is agile and competitive.

    Roadblocks on the Path to Agility

    Driving operational agility is easier said than done. Enterprises face a variety of challenges when it comes to streamlining their end-to-end processes, including a lack of visibility into business gaps, monolithic legacy systems, siloed departments and evolving regulatory requirements.

    Enterprises have no choice but to overcome these hurdles and streamline their operations or else they will fall behind their competition.

    Now more than ever, business and IT leaders must recognize the importance of investing in business agility when it comes to their bottom line. Especially since, as the Gartner report said, “agile software development practices are fueling software innovations globally. Agile techniques create more value for the business, and faster, than do traditional methods.”

    The real question is: how can enterprises seamlessly shift to a more agile operating model?

    Agile Operating Model: The Four-Step Approach

    Understand Business Needs

    An effective agile operating model is rooted in a comprehensive and deep understanding of an enterprise’s needs and gaps. This goes beyond identifying business goals, requiring organizations to analyze the nuances of their operations, the challenges impacting day-to-day functions and all their expected outcomes.

    Based on this holistic picture, business leaders can begin to recognize which technologies and strategies to implement and where to generate the most return on investment (ROI).

    Connect, Collaborate, Contextualize!

    The bedrock of agility is a connected enterprise, and so bridging operational and departmental silos is of the utmost importance. Every relevant stakeholder across the organization must have complete visibility as well as access to collaborative tools such as live dashboards, remote and mobile functionalities and personalized user interfaces.

    By leveraging modern technologies to enable anytime, anywhere collaboration, enterprises can make intelligent decisions and changes without compromising on speed or quality.

    Focus on Generating Value

    Of course, the overarching goal of implementing an agile operating model is to generate business value; however, to ensure that expected outcomes are met, enterprises must clearly define—and periodically redefine—how value and ROI are assessed.

    By leveraging process analytics and monitoring tools, business leaders can maintain complete visibility into their operations, quickly readjusting their approach whenever necessary.

    Empower Employees with Modern IT Infrastructure

    Organizations can drive continuous improvement and increase productivity by embracing modern technologies and low-code development capability.

    To respond to the evolving business needs, enterprises can leverage new-age technologies, including cloud, robotic process automation, artificial intelligence and machine learning while maintaining a well-integrated IT infrastructure.

    Furthermore, with low-code, enterprises can empower their employees by helping them easily develop applications per business requirements, with less dependence on IT.

    Agility: The Need of the Hour

    There is no slowing down for modern enterprises. To successfully navigate growing competition, heightened customer expectations, and a continuously evolving market, organizations must prioritize business agility.  In fact, “with the speed of change expected to continue, the need has never been greater for an operating model that can keep up.”

    And so, for business and IT leaders with their eyes on the future, the time is now to take steps toward establishing a more agile enterprise.

  • Nolij Consulting Brings Expertise Beyond the Public Sector

    Nolij Consulting Brings Expertise Beyond the Public Sector

    Alan Shimel talks with Ashley Mehta, CEO and president of Nolij Consulting, about the company’s deep expertise in health care IT, digital health care transformation, testing and evaluation, and the use of emerging technologies to solve issues in the government IT space. Now, the company is going commercial, and Mehta explains how their expertise can benefit IT organizations beyond the public sector. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hey, everyone. Welcome to another session here on TechStrong TV. We’ve got a new company, a new guest, first-time guest to introduce you to today. I want to introduce you to Ashley Mehta. Ashley is a founder, CTO of a company called Nolij. It’s not spelled the way you would think though. I’m going to let her explain that. Hey, Ashley, welcome to TechStrong TV.

    Ashley Mehta: Thank you, Alan. Thanks for having me.

    Shimel: It’s a pleasure to have you on. So I know I already said it so I guess we’ve got to address that first. How do you spell the company’s name?

    Mehta: It’s N-O-L-I-J, it’s a play off of knowledge. You know, so I had some friends in the Silicon Valley and they said you have to kind of spell a little different, so that’s what we did when I started the business, yes.

    Shimel: Excellent. Well, I guess the question is let’s share with our audience, let’s assume they don’t know anything about Nolij. So why don’t we give them a quick background there and then we can talk a little bit about your background as well.

    Mehta: Yeah. No, that sounds great. So Nolij is a woman-owned small business. We started in about 2012. I had worked for some large consulting business to learn all the ins and outs of the business and management side, and slowly just kind of started building my woman-owned small business.

    Today we have around 150 employees and we are primarily a health IT company doing work within HHS and the Defense Health Agency. We also do work within Homeland Security within the GSA. So it’s been a lot of fun and we have an outstanding company.

    Shimel: Absolutely. Very cool. People think, oh, startups, overnight success. You’ve been at this now for about eight or nine years, and as have I here at MediaOps, working on eight years now. You know, you put everything you got into it, right? You said you worked for some big consulting companies, but give us a little bit more of your background if you don’t mind.

    Mehta: Yeah. So I’m originally from Ohio, went to Ohio State University, graduated in marketing.

    Shimel: OH.

    Mehta: Yeah, yeah. The Ohio State University. We have the Buckeye fans within our family. My dad has had his own business. My oldest brother’s in healthcare in mergers and acquisitions and doing very well. I’ve got a twin brother that’s also in technology and business. And then my dad was, like I said, had his own business, and cousins and uncles.

    So we have a big background in basically finance and entrepreneurs and business and I guess it’s just kind of a little bit in my blood.

    Shimel: Good for you.

    Mehta: Yeah. So it’s been a lot of fun.

    Shimel: Yep. So recently Nolij expanded into the commercial market.

    Mehta: Yeah. So actually before COVID hit we started kind of thinking about, hey, let’s start exploring into the commercial market, see what’s out there. We do a lot of work within, like I said, health IT. We thought, hey, let’s go and see the private hospitals. We do a little bit of work within the private hospitals in regards to the contract that we have with the Department of Defense, working with them to make sure the electronic healthcare records are integrated with our system, so if any of the military personnel have to go into the private hospitals that their electronic healthcare records are there.

    So we’re really just venturing out, getting our feet wet, figuring out if it’s going to be a viable market for us, and hired experts within the commercial markets. So we’re experimenting with the private hospitals and we’re also going to start to experiment with the payers as well, but we just have a very energetic workforce, great employees, a lot of technical talent, and just really trying to figure out how else we can grow. So of course started it before COVID hit and then COVID was interesting.

    Shimel: To say the least. [Laughs]

    Mehta: Yeah, yeah. But we focused a lot on marketing and kind of getting our name out there, so thanks a lot for this opportunity, Alan. It’s a pleasure and really, truly appreciate it. [Laughs]

    Shimel: Oh, no. It’s our pleasure. I mean, part of what we like to do is bring interesting companies, interesting service products to the audience so that they understand. So you’re doing this, let’s say, going on seven years, and you say, you know what, we’re going to – when did you decide to say, okay, we need to get into that commercial market?

    Mehta: Yeah. That’s a great question. So one of our largest projects is within the Department of Defense, the Defense Health Agency. So we actually have the pleasure of actually doing the IV&V for software testing for the electronic healthcare records on the Department of Defense Side. And Alan, I’m sure you’re probably familiar with that they’re trying to commercialize the product. It’s called MHS GENESIS, which is a Cerner commercial product, and Dentrix, which makes up MHS GENESIS, which is basically the Department of Defense’s electronic healthcare records that will flow digitally into the VA.

    So once you retire from the military and you become a veteran you don’t have to literally hand over your healthcare records to the VA and have them scan it in and upload and that kind of thing, that it’s just all electronically. So it’s just better care for the people that serve our country. And so we’ve been doing all this support, making sure that there’s no defects and that kind of thing within the software. I think it was just kind of a point where, hey, it’s a large project, we do an outstanding job, we know the ins and outs of interoperability and data and defects and how to mitigate a lot of the risk with them in technology and software, which is very complex because there are so many systems that are integrated to make up these electronic healthcare cords.

    So we were just thinking that, hey, let’s venture out into the commercial side, see if we can get some business there, provide opportunities for our employees to grow, for the company to grow, and I think it’s always great to get the expertise and get the guidance, and then you’ve got the resources to do the work, but just kind of see what else is out there. So that’s what we’ve been doing. Because you always have to build upon the capabilities that you have, and so the commercial market there’s a lot of opportunities to do that.

    Shimel: Absolutely. I want to bring up something, and I hope I don’t embarrass you, but obviously Nolij is a woman-owned or woman-founded run business. In the federal space we have, you want to call them, set-asides for minority, women-owned business, economically-disadvantaged community businesses, stuff like that. We don’t have that as much in the commercial space, frankly. So I wanted to ask you – and I realize you venturing forth into the commercial market is rather new for you, but how do you find it as a woman CEO? The differences between navigating what for you is the comfortable confines of the gov space versus kind of the wild west of commercial.

    Mehta: We’re not really focused on the fact that we are – I mean, we are woman-owned because I’m a woman, but we’re really focused on the customer and the technology that we have to offer. So we have to get out there, submit excellent proposals that have to do with emerging technology to help increase efficiencies and decrease risk for clients. Quite frankly, I think on the government side I think I’ve only submitted maybe one or two proposals that are set aside for woman-owned small business. A lot of them are small business and if a woman happens to own it then the government gets those brownie points and allocates those towards woman-owned small business.

    But I don’t see tons of opportunities set aside specifically for woman-owned small business. Maybe on subcontracting plans, if it’s a large set-aside, then they’ll say, okay, you have to give 5 percent to HUD zone and 5 percent to woman-owned and 8A and that kind of thing. But I don’t think that – at least I haven’t seen within the agencies that I have been doing a lot of work in, real strong set-asides for woman-owned small business where women are actually competing to win the work. I mean, a lot of times you see these companies that quite frankly are owned by men [laughs] that get their wives to be the woman –

    Shimel: Oh, I saw plenty of it. Yeah. One of the companies I founded was about 60 percent of our business was DOD back in –

    Mehta: I’m sorry, say that again, Alan. I didn’t hear that.

    Shimel: Sixty percent of our business was DOD. This is like in the mid 2005 to 2010 timeframe. And back then it was like native-owned business as a lot of set-asides. And I saw this firsthand and it got me really down on that whole line of doing things. It was like a good idea; try to give native-owned businesses business, right?

    But then what they were doing is you would have like this small native-owned business that had one person who as a Native American as the titular head/owner of the company, and then they were just kind of acting as a front for the usual suspects, right? [Laughs] The large integrators. And I realized it was a good idea but in practice it was abused and it’s not what the intent there was. It was wrong.

    Mehta: Yeah.

    Shimel: It is. So let me ask you a question. For people out here watching this now, when should they reach – what is the fact pattern, if you will, for when they say, hey, you know what, Nolij may be something that can help us here? Nolij is a company that might be able to help us.

    Mehta: What is the what? I didn’t hear that.

    Shimel: What is the fact pattern or what is – give us a typical engagement sort of scenario. Commercial companies out there saying, you know what, I’d like to reach out to these folks. They might be able to help us with this problem.

    Mehta: Yeah. So we have lots of technologists that are in the areas of quality assurance and software testing, artificial intelligence, RPA, which is robotic process automation. We’ve just recently partnered with probably about eight different emerging technologies, different various artificial intelligence platforms that either helps out with customer service or help out with operations, like a lot of bots. But I would say that the whole integration of systems, getting them to work, making sure there’s no defects, because at the end of the day it’s like the customer, they’re using these systems and they have to be happy, right? Especially when you’re dealing with people’s sensitive information in regards to their personal health information or their personal data, cybersecurity.

    We’re also kind of partnering with companies that have various cybersecurity technologies. So I think that we’re just kind of out there. And as a small business, you have to have strong partners to grow as well. Even large businesses have to have small businesses to grow because they have expertise in certain fields. So it’s really just about just building those strong partnerships, being able to go in, do the work with the clients, and just be successful in just making the customer successful. So I think there’s a lot of trust there that kind of goes into that when the customers give you an award.

    Shimel: Absolutely. Ashley, you know what I realized? We got into the whole how do you spell Nolij, but we never gave the website for people who may be wanting to get more information. What is the website and if you could spell it.

    Mehta: Sure. It’s obviously W-W-W dot N-O-L-I-J consulting dot com.

    Shimel: Very cool. Nolij Consulting with an N. I love it. Ashley, thanks for being our guest on TechStrong TV today. Great continued success. Best wishes. Come back and keep us posted.

    Mehta: Thanks, Alan. I definitely will do that. Thanks. I appreciate it.

    Shimel: Very cool.

    Mehta: Thanks.

    Shimel: Alright. Thank you. Ashley Mehta, CEO, cofounder of Nolij Consulting. That’s N-O-L-I-J, here on TechStrong TV. We’re going to take a break. We’ll be right back.

    [End of Audio]

  • Multi-Cloud Is Not About Lift and Shift

    Multi-Cloud Is Not About Lift and Shift

    Multi-cloud is often framed from the perspective of “lift and shift.” In other words, an organization takes a computing environment previously running on one cloud and transfers it over to a different service provider. Cloud migration may make sense for cost savings or performance benefits and such a shift may be necessary when migrating on-premises data centers to a public cloud.

    In theory, lift and shift sounds like it would empower cloud consumers with more choice in the marketplace. However, according to John Gentry, CTO of Virtana, lift and shift is quite rare in practice; it may not be the true driver behind multi-cloud strategies. Moving resources between clouds can result in costly egress fees. Plus, culturally-ingrained cloud preferences become challenging to shake. Unique configurations and add-on software-as-a-service (SaaS) make each cloud more nuanced, requiring new skills and procedures with every migration.

    Instead, Gentry advocates for a “fit-for-purpose cloud” strategy. This attitude is less about moving similar workloads between clouds but, instead, pairing particular types of workloads with the appropriate cloud types. According to Gentry, using multiple clouds simultaneously could still help organizations strategically align their digital resources and reduce dependency on a single cloud service provider (CSP). But, the real value of a hybrid multi-cloud setup lies in matching computing environments to different business layers.

    Fit-For-Purpose Cloud

    At first glance, the ability to move between clouds appears to be driving a new multi-cloud economy where cloud strategists can swiftly migrate resources and optimize intercloud utilization. However, when organizations attempt to shift, they usually experience many hidden costs, Gentry warned. These often pop up around data egress. Or, new data storage costs may take a surprising toll, Gentry added. “A lot of companies look at it from a computing perspective and they don’t account for the storage footprint.”

    DevOps in the cloud also introduces new responsibilities and processes that may differ between clouds, continued Gentry. From unique storage operations to managing the life cycle of a virtual machine, each cloud carries unique configuration methods. This makes it more difficult to abandon established procedures in favor of a different computing arrangement.

    Nevertheless, Gentry recognizes that we’re starting to see a maturing effect of the multi-cloud concept, especially among large enterprises. “Companies have a multi-cloud strategy—it’s less about moving between clouds than about picking a cloud that has specific advantages for a given workload,” he said. In a fit-for-purpose cloud approach, different workloads correspond to different layers of the business. For example, an organization may require a local data center or private cloud for high-security data. Certain applications may benefit from a distributed global public cloud, whereas other workloads could reap performance benefits and cost savings from a cloud-adjacent edge model. “These specific areas may not have anything to do with one another other than supporting the overall business,” explained Gentry.

    Matching Cloud Types to Business Units

    So how do we match the workload at hand to the ideal computing arrangement? Gentry identified three emerging cloud types:

    • Private cloud: A private core for particular functions that can’t be replatformed or rearchitected. Business areas such as financial records or patient care hold sensitive data that must be stored properly to meet regulations and SLAs.
    • Public cloud: End customer-facing, where sensitive data is not an issue. Public distributed cloud is ideal for delivering a highly available front end for customer-facing digital experiences.
    • Cloud adjacent/edge: When an environment is kept in a cloud adjacent facility with relatively local geographies. This may sit alongside the public cloud or connect to a front end in a cloud.

    For example, Gentry described how a large health care company uses a hybrid multi-cloud setup to support various business divisions. The organization is keeping traditional patient care workloads exclusively on-premises; due to regulatory reasons, it will never see the inside of a cloud. Yet, they are simultaneously building the next generation of applications in a public cloud, using Google Cloud to scale a clinical trial division. Simultaneously they began using Microsoft Azure for their back office. This scenario highlights one peculiar advantage of late-stage cloud adoption, noted Gentry: “They had the advantage of being able to take a more thoughtful approach.”

    Gentry described another case of an organization performing genomic sequencing. For data-heavy applications like this, where there is a high dependency on input and output, syncing with a public cloud could be extremely costly and introduce latency. For them, the most cost-effective method was to use a cloud-adjacent or edge model alongside a public cloud.

    How to Leverage Fit-For-Purpose Cloud

    One situation that may warrant cloud migration is a complete replatforming, noted Gentry. He described one early cloud adopter that rushed into AWS, only to find it wasn’t cost-effective for their needs. Architects then had to make tough decisions to determine what would be repatriated back to local data centers and what should remain in the cloud. “Their only motive going from cloud to cloud was, ‘We made a bad choice and we want to move.’”

    Clearly, to match cloud use with business requirements, you must choose the appropriate cloud. AWS is widely adopted for elastic computing and offers a wide product catalog. GCP is offering feature innovation and cost reduction to compete and is going after un- and under-penetrated regions. Azure, on the other hand, will offer licensing advantages if you are a Microsoft shop.

    Secondly, to unite IT around a hybrid multi-cloud strategy, you must remove the adversarial state between traditional ops and cloud ops. Classic ops is typically very safety-oriented, using a slow approach with endless tests in pre-production. Traditional ops may produce yearly updates. This is directly opposed to the new cloud ops approach, which emphasizes agility, speed and constant deployment. “They sit in different silos,” Gentry explained.

    To solve this dilemma, companies must share technical skillsets between the three main cloud types. “DevOps must become a continuum for all types,” Gentry said. In addition to cultural change, DevOps tools must evolve to monitor workloads across a hybrid multi-cloud estate. This will require integration to tie together tools and deeper observability.

  • How No-Code Will Transform DevOps

    How No-Code Will Transform DevOps

    In the years that low- and no-code development tools have been available, the movement has been slow to gather pace. Until recently, the vast majority of app and workflow development has remained firmly in the hands of professional coders.

    That is about to change—and fast. Gartner forecasts that the global low-code development technologies market is on track to reach $13.8 billion in 2021, an increase of nearly 23% over 2020. Other research suggests that 20% of all workers use no-code tools today, including 56% of coders. And 71% of those who use no-code tools within IT adopted them within the last year.

    No-code development is reaching a tipping point, and this trickle of adoption has turned into a torrent, driving more and more business demand daily.

    Drivers for the No-Code Movement

    The reason for this acceleration is simple: Digital transformation requires speed. If businesses are to digitize the full universe of processes across all departments, then they need tools that can be adopted quickly and with little ramp-up time.

    No-code tools are an ideal solution to this problem, and not just for a short-term fix. If the investment is seen solely as a short-term fix to immediate problems, it’s very likely that a company’s digital transformation efforts will continue to die on the vine. Digital transformation is not a “one-and-done” process; it’s only the start of a new business strategy based on continual innovation, where new apps and tools are built and rebuilt, time and again, to keep up with changing market dynamics and customer/employee requirements.

    The long-term trend of digital transformation has been accelerated by two shorter-term trends. First, obviously, is the COVID-19 pandemic. The social distancing measures used to control the virus meant that businesses had to create new apps and workflows (in hours or days) if they were to survive. No-code tools played an important role in helping businesses adapt at a breakneck pace, and gave them a taste of just what’s possible with intuitive app and workflow development.

    Second, a shortage of skilled developers. The population of 24 million global developers accounts for just 1% of the overall workforce, leaving businesses short-handed and looking for ways of empowering non-coders to take control of app development for themselves. As well as plugging skills gaps, no-code also meets demand from employees for more autonomy and more control over their operations, projects and workflows.

    Unlocking Innovation

    The net result of these drivers is that no-code is now a bona fide movement, and technology companies large and small are taking advantage of market innovations to transform what it means to build websites, software applications, workflows and mobile apps.

    The impact on enterprises will be profound. As Accenture highlighted in its 2021 Technology Vision, no-code is part of the broader democratization of IT, where the ability to create technology solutions to address business challenges is extended to everyone in the organization. This trend will unleash a wave of “grassroots innovation” that will help companies reinvent themselves in the years ahead. Those that fail to take this opportunity now may struggle to keep up with more inventive and agile competitors later.

    What No-Code Means for Developers

    For developers, this trend will undoubtedly lead to many questions. What is the role of the professionally trained coder in a no-code world? Will DevOps become extinct as “citizen developers” take over? Far from causing detrimental effects, no-code and low-code will likely prove to be hugely beneficial overall. Here are four key reasons why:

    Reduced workload/stress. With no-code-based roles, organizations are able to expand their technical capabilities without needing to hire more developers or coders. What’s more, by spreading basic app and workload development tasks across the organization, developers’ time is freed up. For teams that are already understaffed and under pressure, this can make a huge difference in the workplace experience and enable developers to spend more time focused on delivering high-quality software.

    A more strategic role in the enterprise. With tactical software development carried out within business units, developers can spend more of their time focused on the ‘next big thing,’ whether that’s mixed reality, quantum computing or AI. Developers and the wider IT team can act as “futurologists”, assessing new tools for the best fit within the business and guiding purchasing decisions to ensure the best possible outcomes.

    Accelerated innovation. For more complex software development that requires coding expertise, developers can leverage the speed of no-code to spin up proofs-of-concept and test them before investing time and resources on full-scale development. In fact, research suggests that many developers are already taking this approach, with 38% stating that they use no-code for prototyping a new product.

    New roles and opportunities. No-code will have a deep and broad impact on the enterprise, changing how work is done and creating new roles in the process. Many of these roles will provide new career paths and opportunities for developers, such as no-code consulting (helping businesses find the optimum no-code framework and tools for their needs) and roles that revolve around optimizing processes, building solutions and discovering ways to easily automate and streamline the day-to-day work within their organizations.

    DevOps teams, long the drivers of digital transformation, are now finally feeling the effects of those efforts. A new world of work is emerging where everyone is a technologist; using intuitive tools to rapidly build solutions to their business needs as they arise. This approach will free developers from their traditional role as gatekeepers of innovation, allowing them to focus on strategic technology decisions and channeling their specialist skills to areas where they will make the most impact.

    The rise of no-code is good news for everyone. It accelerates digital transformation and unlocks the innovation potential of all employees. And it’s great for developers, too; making their work more interesting, less stressful and with new career paths and opportunities for development. No-code can provide a growth driver to all enterprises, and arm early adopters with a significant competitive advantage.

  • The State of DevOps Is Just Fine

    The State of DevOps Is Just Fine

    There is a growing amount of hand-wringing about the state of DevOps; that adoption is not progressing apace, or that the full benefits of the methodology are not being realized by the majority of adherents. That we can and must do more and do it better, etc.

    That is just stupid. Or, my first reaction: “Bunk!”

    Yeah, I called an idea stupid. No, I didn’t call you stupid. Don’t give me a reason to. The world is full of stupid ideas, and this is one of them. Here’s why.

    DevOps has seen a decade of unprecedented adoption – yes, unprecedented. PCs were not adopted by businesses at the rate that DevOps was adopted, once it caught on. Virtualization took the business world by storm and, frankly, wasn’t even close to the adoption rate of DevOps. Agile greased the wheels and got people thinking about better ways; we all knew the weaknesses of how we were doing things, and DevOps gave us an option that addressed those weaknesses. We took it. We ran with it.

    So talking about how it is stalled, when adoption is darned near-ubiquitous? Silly.

    Those concerned are further zeroed in on one aspect of DevOps – not enough culture change. Let’s face it—automation is easier, the ROI is more obvious and even when ROI is vague, the elimination of busywork from the schedule of developers and operations alike is huge. Some organizations were never going to move beyond that point; others eventually will, but aren’t in a rush. Organizational changes do not define DevOps any more than automation does—DevOps is the process of streamlining software creation and delivery—and both automation and culture change contribute.

    The “full benefits” of DevOps are … what, exactly? That is another silly part of the proposition that a slowing of DevOps adoption is negative. Automation improves the creation and delivery of software, silo elimination improves the creation and delivery of software… The full benefits of DevOps are improvement. That has always been the stated goal—to make it better, smoother, more repeatable. Wherever an organization is on implementation, it is almost guaranteed that their creation and delivery is “better, smoother, more repeatable.” So, benefits are accruing.

    And each organization has different needs. DevOps is a methodology. It has never been the perfect solution to every IT problem—though there are still pundits that will try to tell you it is. Automation is always a positive; Agile and DevOps—well, that is less true. You know your organization and your apps, so the “right methodology for the job” is absolutely your call, not some vendor’s or pundit’s. So, “adoption slowing” partially represents orgs/projects/apps that have opted not to pursue some of the more radical changes DevOps implies (yes, radical. Automation is just a logical extension of scripting; redesigning team organization and reporting relationships is absolutely radical by comparison).

    Which is a good place to leave off. Your apps, your org, your environment. You know what is going to do the most good. So keep doing it. Push for it if the org isn’t there yet, be the change that is needed. But be aware of cost/benefit. Sometimes, the changes being asked for just aren’t worth it. So make sure they are before you push too hard, and if they’re not, make sure you’re comfortable with why and can defend that decision.

    And keep rocking it. Those apps are delivering to users, no matter where you are in DevOps adoption. And that says it all about you and the team. Thanks, for all of your users that never think to say it.

  • Shopify Gives Devs More Creative Freedom

    Shopify Gives Devs More Creative Freedom

    Shopify’s Unite 2021 conference was held on June 29, 2021, and the e-commerce platform had some big, developer-centric news to share. Alan Shimel spoke with Shopify’s Glen Coates about the developer-first business model that is giving developers the most opportunity to build their businesses with a new 0% revenue share model, and how developers can leverage as much creative freedom as they want, from low-code capabilities in Online Store 2.0 to “max-code” custom storefronts. The video is below, followed by a transcript of the conversation.

    Alan Shimel: Hi, everyone. Welcome to another TechStrong TV segment. My guest this segment is Glen Coates. Glen is with Shopify. Glen, welcome to TechStrong TV.

    Glen Coates: Thanks, Alan. It’s great to be here, man.

    Shimel: It’s great to have you on. Glen, no pressure, but I think you’re the first person from Shopify who has been on TechStrong TV.

    Coates: There you go. _____ [inaudible due to audio distortion] it’s going to be all up from here, like you’re starting at the right place.

    Shimel: We’re starting at a low bar.

    [Crosstalk]

    ‒ it only gets better. We’ll see. Anyway, Glen, I think our audience doesn’t need an introduction to Shopify. We’ve all bought things online through Shopify storefronts and so forth, but why don’t we talk a little bit about you, your background, your position with Shopify?

    Coates: Right. I’ve been at Shopify a couple of years now. Before Shopify, I founded a startup called Handshake, and Handshake was a wholesale-focused e-commerce platform, so very much like Shopify but not focused on direct-to-consumer selling, just on wholesale. Handshake was acquired by Shopify about two years ago, so I’ve been at Shopify since the acquisition. In my time in the last couple of years at Shopify, I initially started out focused on wholesale, obviously, given my background. I spent most of last year focused on Shopify’s checkout, which is, obviously, a pretty important part of Shopify, and then about six months ago, _____ _____ product for what is called Shopify Core.

    If you’re a merchant, Shopify Core is like what’s in the box when you buy Shopify. It’s the online store, it’s the checkout, and it’s the back office admin that lets you set up and run your business. If you’re a developer, Shopify Core is the core developer platform, so the APIs, the dev tools, the docs, all the things that let you build apps and themes and work on the Shopify platform. Yeah, and, obviously, it’s a big responsibility and a really exciting role to be able to help the world of entrepreneurs start and try their business ideas.

    Shimel: Absolutely. Glen, just to give a little color, how many different Shopify merchant stores are there, whether it’s sheer number, percentage of commerce, or what have you?

    Coates: Yeah. Today, Shopify powers almost two million merchants. I mean, obviously, the last year has been kind of an accelerant to businesses going online, and that’s both been new businesses, people trying businesses for the first time, and it has also been traditional businesses going digital more quickly than they might have otherwise. But yeah, today, Shopify powers almost two million merchants worldwide, and it wasn’t that long ago that that was only a million. Even at massive scale, even being the world’s largest commerce platform in terms of number of merchants, it’s still growing very quickly, which I think just goes to the pace at which the world of business is going online, and how many people want some help with that.

    Shimel: Got it. Excellent. Thanks for all that info. If you don’t mind, let’s turn to the topic of today’s conversation, and I’m going to let you explain it, if it’s okay.

    Coates: Sure. Next week, it is Shopify Unite, which is our annual conference. Over the years, Shopify Unite has been focused on a combination of merchant and developer topics, but this year we’re really doubling down on developers, and really making it a developer-centric conference. The reason for that is sort of going back to the question you asked me a second ago, is Shopify was founded in Canada, and, if you go back five, six, seven years, Shopify’s mission has always been to make commerce better for everyone. But, if you go back half a decade, it was mainly North American merchants mainly selling apparel, mainly direct-to-consumer, which that’s a big market but it’s not the world of commerce.

    Over the last few years, Shopify has expanded considerably into new industries, new countries, new ways of welling, so wholesale as well as retail, and so we’re now in a much more diverse world of commerce, different businesses doing different things. As we sort of march down the road and try to fulfill that mission of making commerce better for everyone, that everyone is becoming a lot more diverse as we expand. Shopify can’t build all the solutions for everyone, all those different niches. While we have a great core product that includes many of the out-of-the-box things that people need to start and run a digital business, it’s not everything. We need the help of the world of developers to help build those solutions for the markets for the spaces that they are experts in to complement what is in Shopify Core, and really deliver everything that merchants need to successfully start, run, and scale a business.

    This year, we’re really focused on developers and helping them get onboard with our platform. There are really three main legs to that, I would say. The first one is mainly technical. I think for your audience, some of those details are important, like Shopify really is expanding to be PlanetScale commerce infrastructure, really becoming the power lines, the plumbing, the electricity grid that runs the world of commerce. So, we’ve done some things to really scale up our infrastructure that if you’re a developer building on Shopify, you can be confident your stuff is going to run at global scale without you really having to do anything. Our checkout can handle seven times the load that it could before. We’re now at greater than 30,000 checkouts per minute on a single shop.

    It’s interesting what’s happening to the world of commerce, like the world of social selling has made, and the way algorithms reinforce themselves in terms of distribution to drive traffic towards things that are trending. It’s become more important than ever that a merchant who blows up, whether it’s because of them being re-shared by an influencer or whatever it is, that they can capture that demand in the moment. Traffic is basically getting more spiky on the Internet. When things trend, they trend fast, and so Shopify already was the highest throughput checkout on the Internet but it’s now 7x higher, so merchants should never worry about not being able to make the most of those moments when they’re trending becoming more and more important.

    Shimel: It’s hyperscale, is what it is, Glen. We’re seeing it not only in merchants and commerce, but across everything. The Internet is big business, it is worldwide business, and especially with COVID, right? If you haven’t built your infrastructure to hyperscale, you’ve got trouble.

    Coates: Right.

    Shimel: That’s what digital transformation is about. That’s what the world is demanding right now, hyperscale.

    Coates: I imagine the readers, viewers of your site are not strangers to the world of what it takes to scale websites, and I think a lot of what Shopify tries to do is say, “Well, listen. We’ve figured that out for you. You’re a merchant with an idea. You’re going to come up with a new shoe or a new candle,” or whatever it is. Entrepreneurship is a risky endeavor, not everyone succeeds, but, when you succeed, like we really want you to be able to just capture the whole thing. The checkout works at one checkout a minute when you’re just starting out, and then, on your biggest days, it goes to 30,000 and you just don’t have to do anything. It just works, which is great. Kind of piece number one of Unite this year is Shopify really is PlanetScale infrastructure for commerce, and we already were the leaders and we’ve kind of gone up another multiple from there. Point two is really like, “As a developer, what things can I build on your platform? What are the opportunities for me to innovate, like where can I do that, and why is that exciting?”

    We’ve made some major updates to our online store, to our themes platform, which is obviously every merchant basically runs an online store with a theme on it. There is a new themes platform that allows developers to properly separate basically data and presentation into different layers in a way that makes themes more modular and extensible and kind of upgradable in the future. We have this powerful new data infrastructure that allows merchants and developers to essentially build custom data models inside a shop, and not just be confined to the out-of-the-box data model that ships with Shopify. There is now a much more powerful customization framework for both theme developers and app developers to integrate custom content into themes without having to hack the theme by hand and try to take it off the upgrade path, which is really great for merchants. We have also recognized that the Shopify online store is based on a web templating language called Liquid, which is similar to the templating languages that all developers are basically familiar with.

    We are also announcing, if you want to, you choose your own stack. If you want to build your website using React or something else that’s not our out-of-the-box stack, we’re also making available a new platform codenamed Hydrogen that will allow developers to basically choose their own stack, build online stores using whatever technologies they want, but ‒ and this is the crucial part ‒ still leverage a global infrastructure and hosting in scale and, “I don’t have to think about it. It’s just going to work,” on the Shopify platform, which is really great and really unique. Last but not least, I mentioned earlier that I spent last year on checkout. We are opening up for the first time the ability for developers to build checkout apps. Checkout is the piece of Shopify that it really matters. It’s where the money changes hands. It has to scale, it has to be super reliable ‒

    Shimel: Super secure.

    Coates: Super secure, super trusted, right, and trusted not just in the technical security sense of the word, but even just in the emotional sense of the word, like when I’m a buyer and I’m buying from an online store, when I see this checkout, does it feel familiar? Does it feel like something I can rely on? Am I comfortable handing over my money? Checkout is really where, in the _____ journey, the emotions shift from at the top of the funnel it’s kind of, “Okay, your brand, it’s really different. It’s exciting. I want to see differentiation. I want to be challenged and see new things.” But, when you’re handing over your money, the emotional tone is different, right? You’re not looking for excitement, you’re looking for predictability, right?

    Shimel: Yeah.

    Coates: Historically, Shopify’s checkout has been less customizable than the actual storefront pages higher in the funnel, and so now we’re opening up a new extensions framework for checkout that allows developers to build in apps that securely extend the function of Shopify’s checkout without compromising on the trust, the scalability, the speed, and all those kind of baseline, crucial things.

    Shimel: Very cool.

    Coates: That’s really cool. The last thing I’ll mention is we’ve talked about, “Okay, as a developer, if I build on your platform, is it just going to scale to the world?” The answer is yes. “Okay, so then what am I going to build?” Okay, so there are a bunch of new programming surface areas that we’re opening up for people to build apps and themes into, and then the last piece is, “What’s in it for me? Where are the dollars? If I start building your platform, am I actually going to make any money as a developer?” One of the things we’ve announced is _____ economic opportunities for developers. One is we’re cutting the rev share on apps in the Shopify app store to zero for the first million dollars in revenue per year, and, after the first million dollars, we’ve actually cut our rev share from 20 percent, which was already one of the lower rev shares in the industry, down to 15 percent. We’re really trying to help developers who have an idea for an app or an idea for a theme get that off the ground, no rev share on that first million bucks, and we really just want to help developer entrepreneurs get going as easy as we try to help merchant entrepreneurs get going ‒

    [Crosstalk]

    Then, the second one is that the Shopify theme store has historically not been open for submissions from any developer who wants to build a theme. There has been a sort of a curated set of themes there until now, but we’re actually opening up the theme store, so developers who want to build a theme and sell it to merchants will now have that opportunity that they didn’t before, which is also a huge market that is new.

    Shimel: Look, I think emphasizing the developer and the developer interaction in Shopify is huge. Glen, this is all great. I didn’t want to stop you when you were talking, but of course we’ve pre-recorded this show and it’s now playing after Unite has already taken place, I believe, on the 29th.

    Coates: Right.

    Shimel: But, for people who maybe want to see a replay of it or maybe get the highlights, is there a place we could send them to check it out?

    Coates: Yeah, if they just go unite.shopify.com, they’ll be able to watch the keynote and then dive into the other sessions that were part of the event and dig into whatever they would like.

    Shimel: Fantastic. Glen, thanks for a great recap on what happened at Unite and what’s going on at Shopify. Please come back on and keep us posted. You were wrong. You set a high bar. It’s going to be tough for people to beat, so come in and please keep us up to date on what’s going on at Shopify, especially with this renewed focus on developers and development options on the platform.

    Coates: I appreciate your time, man. Thanks for having me.

    Shimel: All right. Glen Coates on Shopify, about Unite, the Shopify conference here on TechStrong TV. We’re going to take a break and we’ll be right back with another guest.

  • DevOps Database Platforms Slash DX Bottlenecks

    DevOps Database Platforms Slash DX Bottlenecks

    An enterprise with many databases and various data requirements for DevOps continuous delivery presents a problem. For example, test data provisioning is a challenge today, particularly in pre-release testing of database updates. Standard practices involve shared database environments that need to be maintained from one test to the next, slowing test cycles and generally not fitting into an automated CI pipeline. As I explained in A New DevOps Database Platform is Needed, at best, it makes things chaotic; at worst, problems with database integrations with DevOps is a gross impediment to overall organization agility—which undermines the very purpose that DevOps is meant to serve.

    A recent whitepaper, A New Kind of DevOps Database Platform, indicates that there are multiple reasons why a new kind of DevOps database platform is needed, which are:

    • Compatibility requirements
    • Integration with current CI/CD pipelines
    • Integration with portfolios of value stream management
    • Infrastructure cost efficiency
    • Productivity for developers, testers and operations
    • Security and governance
    • DevOps performance

    The paper explained that a DevOps database platform requires the following capabilities to satisfy these requirements.

    • Automated database provisioning: the ability to deploy a database using automated procedures.
    • Database cloning: writable database environments are delivered on demand, based on a built versioned image.
    • Distributed repository: database images can reside on Linux and Windows servers, as well as storage systems.
    • Simple declarative builds: a simple, predefined method to make the creation of versioned data images simple, while enabling user/group access controls, data masking and other data engineering functions.
    • Scalable data cloning: database clones are served on demand, with many simultaneous clones served from a single image.
    • Comprehensive database support: the repo supports all common relational, NoSQL, machine learning and file-based data stores.
    • Versioned databases: each image becomes a versioned, immutable DevOps artifact.
    • Deploys equally to all cloud environments: DevOps databases can be deployed and operated on any on-premises infrastructure or cloud.
    • Cross-platform:  DevOps databases can be deployed and operated on common operating system environments such as Windows and Linux.
    • Security features including access management, data masking and encryption: database images easily incorporate access control, data masking and synthetic test data via SQL scripts, batch files or command line tools.
    • Compatible with CI/CD platforms:  DevOps databases can be deployed and operated equally well in multiple CI/CD platform tools such as Azure DevOps, Jenkins and CloudBees.
    • Compatible with containers and container orchestrators: DevOps databases can be deployed and operated equally well in multiple container environments such as Docker, Kubernetes and Red Hat OpenShift.
    • Deliver writeable data at the speed of DevOps: Deliver writable databases in seconds.
    • API for easy integration with DevOps tools: An API is available to enable integration of the DevOps database control plane with other tools.
    • Audit logging: The DevOps database includes a complete audit log of operations.

    Transforming to the New Database DevOps Platform

    A DevOps database platform in an enterprise requires more than simply buying and installing software and telling everyone to use it. With multiple entrenched database platforms already in place, there are practical and political considerations that must be overcome. Introducing any change to a large group of applications in an enterprise can be chaotic, and will often be more costly and take too much time if the changes are not compelling.

    To be sufficiently compelling, the database DevOps platform needs to be affordable, easy to understand, easy to set up and use with a wide variety of CI/CD pipelines. The following will be sufficiently compelling benefits to drive adoption:

    • Versioned, secure database environments or images managed as a DevOps artifact.
    • Images can be built and managed by the DevOps team, without requiring new infrastructure.
    • Multi-DB and multi-TB data environments in seconds.
    • Database environments can be served on demand for a CI/CD pipeline.
    • Lower-level database environment infrastructure is streamlined, with a single VM capable of supporting many simultaneous database environments which drives an immediate cost savings and positive ROI.
    • Data security and governance benefits with versioned database environments, with built-in and auditable security policies.

    What This Means

    Digital transformation is imperative for modern enterprises and organizations to remain competitive. However, the transformations of many enterprises and organizations are seriously impeded by the challenges of integrating databases into their DevOps application pipelines and value streams. A new DevOps database platform can allow the databases to be treated like any other DevOps artifacts that are orchestrated and automated within the DevOps toolchains.

    Suggested resources for automating database environment delivery include Windocks, Cohesity and other storage appliances that provide virtualized (cloned) database environments that can be adapted for DevOps purposes. I want to particularly acknowledge input from Windocks, who has introduced a DevOps data repo that features database virtualization on standard Linux and Windows servers, for versioned data environments and CI pipelines and cloud-native support for data delivery for containers, Kubernetes and conventional instances.

  • Are You Wasting Money in the Cloud?

    Are You Wasting Money in the Cloud?

    I’m not the first person to point out the issues with Andreessen Horowitz’s blog post outlining why Dropbox is repatriating from the public cloud to data centers and saving an enormous amount of money. But while others have brought up valid points about how Dropbox is not representative of most companies and that the value in public cloud is in speed, not cost savings, I wanted to address a different angle: How do you, as an IT leader, know if or when you should move your cloud workloads back to the data center? How do you evaluate the ROI on the cloud in general?

    I want to talk through some of the factors that companies should be aware of when they’re thinking about whether or not it would be appropriate to repatriate a workload—and perhaps give some IT leaders peace of mind that staying in the cloud is OK.

    How Mature is your App?

    The earlier you are in the application’s life cycle, the more critical access to cloud infrastructure is. Early in the application’s life cycle, you need to get things out the door and test them with real people. You don’t, at this point, actually know how users will interact with your application or how the application will perform under the stresses of actual use. You also don’t know how much it will cost to run.

    At the beginning, quick iteration is also very important. There will undoubtedly be things in the initial release that go wrong—you need a way to quickly adjust course and improve.

    As the application matures, everything slows down. Your information about the application accumulates, but quick iteration becomes increasingly less important. It’s not until the workload is fairly mature that you can begin to understand how much it costs to run in the cloud and can compare that with how much it would cost to run on-premises.

    At the early life cycle stages, using a public cloud provider is extremely valuable because it allows you to get the application into users’ hands quickly and to iterate fast. As the application matures and changes are made less frequently, moving it back to a data center could make sense—at least in some cases.

    Internal Skill Sets

    Running an application in the cloud involves a different skill set than managing a data center. If you don’t have the internal skills needed to staff your data center, that can add not just cost, but will also increase the risk that something goes wrong.

    If you’re considering moving from cloud to a data center, taking a critical look at your internal skill sets is essential. Without a skilled team to manage the data center, you’re better off staying in the cloud even if it’s expensive. And yes, you can hire the skill sets you need, but that requires both time and money.

    Criticality

    If you have a workload that you never want to go down—because it is mission-critical, because it’s revenue-producing—you should probably keep it in the cloud. The cloud is generally more reliable than individual data centers, and the repatriation itself could easily cause disruptions.

    In addition, the cost of running mission-critical applications is less important simply because they are so essential to the business. If the application is burning money but is also your only source of revenue—unless it’s burning more money than it earns, it probably makes sense to keep things as-is.

    Looking at the Exit

    Of course, depending on your application’s architecture, repatriating it from the cloud to a data center could be either impossible or prohibitively expensive. If the application relies on the cloud provider’s proprietary services—databases, for example, or Lambda functions—moving it off of the cloud is going to be extremely hard. Even if it turns out that moving from the cloud to the data center is possible, it could easily cost so much that it wipes out any potential savings from repatriation.

    This isn’t to say that you should never think about leaving the cloud—in fact, if you think moving cloud workloads back on-premises is something you’d like to do at some point, you should consider it during the architecture phase. The decisions you make at that point will determine how challenging it would be to move off the cloud in the future—or even to change clouds if you want to. Using Lambda is going to make moving off the cloud very difficult, for example, whereas using containers will make it comparatively easier.

    When we talk about the costs of public clouds versus data centers, we’re trying to compare things that are fundamentally different. First of all, public cloud costs are notoriously difficult to understand, whereas understanding the costs for on-premises is relatively easy. Sure, there is overhead—building, staff members, etc — but it’s not that different from calculating any other cost in a business and an accountant could make sense of it in 10 minutes with Excel. Good luck doing that with AWS.

    That’s the core problem with cloud costs—humans have a hard time trusting what they don’t understand. But cloud has never been about reducing costs. And regardless, the cheapest option is not always the best option.

  • How ESM Enables Digital Transformation

    How ESM Enables Digital Transformation

    The pandemic has forced organizations of all sizes to overcome colossal challenges and embrace flux. We’ve all heard stories about businesses having to adopt a new communication tool and train staff overnight, but that’s just the tip of the iceberg.

    Many companies are in the middle of fundamental transformation, enabling enterprises to create more business value quickly. Still, digital shifts can also highlight stumbling blocks—such as inefficient management of people, tools and processes.

    As modern business needs grow increasingly complex and require teams to do more with less, C-suite executives have learned that real value lies in customizable systems built for scalability, automation and collaboration. In the same way, companies have embraced DevOps to break down silos between development and operations teams, modern businesses are adopting enterprise service management (ESM) principles to create shared responsibility and opportunity across departments.

    This approach has helped businesses view their digital transformation plans in a new light. Forward-thinking leaders are using ESM to enable a DevOps mindset, to centralize knowledge and ensure efficient digital service delivery within their organizations over the last twelve months.

    The Business Benefits of ESM

    ESM includes the tools and processes that enable an organization to manage the entire life cycle of IT (or other business units’) services. At an organizational level, it can be considered analogous to service-oriented architecture rather than an application architecture level.

    Within larger organizations, multiple teams are often doing similar things to support different parts of the business. Keeping track of requests, prioritizing them and ensuring the right resources are available can be challenging. With ESM, companies can consolidate their resources and provide a consistent way for the organization to consume them. Akin to microservices, employees can easily access shared company services through a uniform interface, streamlining resources management.

    The approach encourages enterprise leaders to see everything the company does as an integral service to the entire business. So, rather than an accounting team merely existing to process purchase orders and take care of payroll, it becomes a service provider. For example, they might create a portal that provides templated service requests for everyday tasks, such as raising a purchase order or understanding if a payment has been received, and a mechanism for capturing ad-hoc work that isn’t otherwise defined.

    The real benefit of this approach is work management. A ticket is raised, and the department dealing with it can have a rotation of people, with whoever is least busy picking up the service request, assessing and resolving it or assigning it to someone else. That’s one reason it’s hardly a surprise that 87% of companies surveyed in 2019 said that they had already incorporated ESM in some way.

    Practices, Not Processes, to Optimize Digitization

    However, with businesses forced to undergo historic digital transformations over the last year, ESM has become even more valuable for organizations. The pandemic has shifted work management to a 100% digital initiative as teams were distributed remotely. A well-executed ESM strategy has enabled enterprises to take their digital-first workflows to a higher level, driving more value from employees and enabling organizations to scale service delivery and create unrivaled customer experiences.

    ESM requires businesses to understand that there is no one-size-fits-all approach to service delivery and encourages them to replace their process-orientated mindset with an approach that focuses on value delivered through practices. These practices, which are built on user interaction and feedback, support agile organizations by helping them accelerate change and make services more available and reliable for customers.

    Furthermore, these practices put users’ pain points and needs front and center to ensure continuous improvement. Through frequent evaluation, enterprises can address the things that matter the most to staff and customers. While this might seem like a basic practice for any company’s digital transformation plans, the truth is in many cases, we’ve found the practice to be widely neglected. A recent report from Eagle Hill Consulting found that one-third of U.S. employees say their company’s technology either doesn’t help or makes it more challenging to serve internal and external customers.

    Digitization driven by these ESM principles can enable businesses to improve operational efficiency, reduce cost and risk, and plan strategically to support their evolving needs. All of these are, of course, what every organization had in mind as goals when the COVID-19 pandemic forced them to rethink how they do business.

    ESM Automation and Cross-Departmental Visibility

    At a high level, ESM sets out to bring all internal services into one place where every employee can easily find what they’re looking for in an instant. Accessing everything in one place also opens the door to leveraging automation. The option for automation means that some previously manual tasks – like providing access to systems – can be automated, speeding up wait times for staff or external customers and ensuring scarce resources, like your best people, are used more efficiently.

    Moreover, common, consistent and shared platforms for all with a single access method gives individual departments enhanced visibility and control throughout the entire organization. Historical silos hampered individual business units’ visibility and understanding of the functions their business provides or how they’re processed. A unified portal where all departments can access resources and receive requests, in the same way, solves that.

    Of course, this isn’t to take away from the inevitable learning curve that comes with digital transformations, especially at the size, scope and scale currently being undertaken. But the turnaround time from disconnected, slow, siloed teams to visible, open, speedy services far outweighs the effort required. In fact, recent research from Digital.ai uncovered just how badly visibility problems and poor internal alignment plagued businesses, with 56% admitting they’re worried that they’ll fail to achieve any return on investment from their stagnant digital transformation initiatives.

    On the other hand, industries like finance, which have upscaled self-service and automation significantly in recent years, have built entirely new business models with collaborative technologies, accelerated innovation cycles, and have learned to make better, faster decisions.

    These companies all embraced technology to empower their employees to help customers get the most from their service. In doing so, they are better able to deliver the best business value, which is core to a DevOps mindset and is achievable with successful ESM strategies.

  • Swinging the Pendulum of IT Back to QA

    Swinging the Pendulum of IT Back to QA

    I was reading Nuria Manuel’s excellent article about quality assurance (QA), and it got me thinking about the wide variety of ‘pendulums’ that impact IT. I call them pendulums because they follow the rule of “every action has an equal and opposite reaction,” and they work on fundamental truths of IT. For example, the one that has probably been going on the longest is centralization/decentralization of IT and its assets. No sooner is everything consolidated and cost savings realized than adaptability concerns and needs of individual business units start the process of decentralization. Then, once decentralization is realized, everyone is painfully aware of the chaos that fifteen miniature IT departments, each going their own way, can cause … and centralization begins again.

    Quality assurance is another such pendulum. Much like soldiers in peacetime, most people don’t recognize the value of QA efforts when things are going well. And when they’re not going well, then it is considered a QA failure—assuming there is a true QA function. Otherwise, it becomes the impetus to launch a formalized QA function … until things are going well and budgets are tight. The problem with QA is that for years, timelines, budgets and Agile management styles have all conspired to swing that pendulum away from a formal QA function. Oh, companies pay the price, but they quite often don’t see it as a cry for a valid QA function, and just treat this particular issue as a one-off that they should make sure doesn’t happen again. Unfortunately, issues in production have become both commonplace and accepted because of this. The only issues in production that seem to actually generate angst are ones that keep users from accessing the product. Anything short of that and workarounds or delayed fixes are seen as okay.

    But the apps you are rush-building today will still be around in 10 years—or, at least, some of them will. Some of them won’t for a variety of reasons–including quality issues. Those that are around in 10 years are going to have to be maintained. QA now can save you over the years, so why all the resistance to it? QA might delay the release of new app. It is understandable that delays are to be avoided if possible, but so are bugs, so maybe constraining how long QA can delay the release and building that number right into the schedule would be a decent compromise.

    That way, QA is looking at the most important/used parts of the app, but not getting buried in the weeds (where there might be bugs, but the ROI for addressing them probably isn’t there). The app will be delivered on time because QA’s time was built into the schedule. This does require that we not allow the traditional and abhorrent practice of shortening the QA window to make up for developers not meeting deadlines. Let us be very clear about this: when developers are rushed because they missed deadlines, that is precisely the time that you want QA to look very closely at their code before release. The last thing you should do is less testing in this scenario. The absolute last thing.

    This is completely doable in your environment. The only really difficult part is holding the line on QA. Business owners are going to want to meet their original timeline, but cutting any phase of testing to get there is just a bad idea, so the struggle will be to hold the line. And figure out why devs missed the deadline in the first place so that the issue can be avoided for the next project.

    You all are rocking it. Make sure all that sweet code-and-deploy work is not undermined by quality issues! Go ahead, implement a QA policy and make it an actual policy. Keep rocking it, get accolades from the rest of us. Maybe even from your employer. Maybe. But definitely from us. Because you’re killing it, month after month.