Johannesburg, 01 Feb 2018
Today's customers want applications to work flawlessly every time across all devices, they want the latest capabilities and they don't want to interact with a human being if they can possibly help it. In turn, companies are increasingly forcing customers to go online in order to interact with them.
However, where customers are merciless in their demands for simpler and faster ways of doing things, large enterprise is traditionally monolithic and slow moving - and this all too often impacts on their application development process. Almost despite itself, enterprise is having to become more agile and innovative, and while this is good for business, it does present some risk to the organisation.
Gary de Menezes, Country General Manager for Sub-Saharan Africa at Micro Focus, says: "Digital transformation, the move to a digital economy, is happening, but is being impacted by a lack of proper application testing philosophies within the large corporates.
"The application is the face of your business, it has to work properly each and every time. Of course, the upside is that you can now monitor people's interaction with your business and extract data from that, whereas previously, when people dealt with people, it wasn't possible to do so."
While there is pressure on large enterprise to be competitive by bringing new and better applications to market without delay, developers and programmers within the organisation are having to find innovative ways of doing so, which includes using open source solutions.
Natasha Simitci, DevOps Portfolio Manager at Micro Focus, says: "Application testing is an interesting space. Globally, over $11 billion is spent annually on application testing tools, but there's been a 6% decline in revenue over the past two years because of the evolution of open source testing tools, which are often free or considerably cheaper than enterprise grade alternatives."
Any new market experiences a sudden influx of new entrants, and this is particularly true in the software development space. Suddenly there's a host of start-ups getting into application tool development, trying to gain a foothold in the market in the hope that they'll be bought out for a large sum by one of the bigger vendors. De Menezes refers to this as the Silicon Valley dream.
The enterprise dilemma
Paul Cripsey, Micro Focus Solutions Consulting Director, says: "We're seeing a lot of corporates adopt open source testing tools simply because testing is usually a short-term project and the traditional perpetual licensing model that enterprise vendors offer simply don't suit short-term testing requirements."
Funding for projects is becoming more focused and allocated for the term of that specific project. In large corporates, it's often easier to get Opex approved for a project compared to getting the go-ahead to increase Capex spend for the year. This is aligning with what's happening in DevOps, says Simitci, where everything is project-based. "You want to be able to acquire an asset for a specific project, use it, then dispose of it, without impacting on the organisation's asset register."
Corporates are now facing a dilemma in that they have an unmanaged proliferation of disparate tools within the same organisation, resulting in up to a dozen different testing tools at any given time across various business units within that organisation, which in itself poses a whole new set of challenges. De Menezes says: "There are concerns around the consistency of the quality of performance that results when you just keep adopting different tools all the time. Particularly if these are open source tools, often they don't go through the same quality development life cycles as an enterprise grade tool. Then there's the consistency of the testing methodology used by the tool, it's possible that you're getting varied levels of quality coming out these tools, there's no consistent high quality output.
"We're seeing a proliferation of these tools across organisations without the usual controls being implemented, such as vendor selection standards that large businesses are accustomed to going through. This becomes even more challenging as corporates increase in complexity and adopt technologies that require mobile applications into the organisation, this is a whole new agile world that corporates just aren't set up to cope with."
Simitci adds: "The other aspect is that if you try to force developers and programmers to all use the same tools and abandon their open source tool of choice, you might create a whole new set of challenges. You need to find a way to integrate the various tools in such a way that your speed to market is where you need it to be."
De Menezes highlights another potential problem: "Another major risk that all of these open source solutions present is around security. If you're bringing multiple open source applications and tools into your IT environment in order to perform short-term testing, you don't really know how secure that application or tool is as it doesn't come from a credible vendor. You need to find a way to bring security into that ecosystem because security is becoming more of a serious issue and attackers are becoming more intelligent in their attacks."
Enterprise needs to make a conscious decision around what tools they bring into their system and test on their core applications, says Cripsey. "A dilemma faced by corporates is that they're unaccustomed to projects that turn around in a couple of weeks."
There's also conflict between the old and new ways of testing. This isn't a new thing. Cripsey adds: "As long as there have been applications - in the region of 25 years - there has been a need to test them. But in the rush to get to market first we're seeing an increase in flawed architecture being implemented into large organisations around application testing."
Previously, DevOps happened in such a small team that the impact on the enterprise was minimal. The more teams that adopt agile DevOps, the more it will impact on the enterprise and the more important it becomes that they cease operating in a siloed approach. Teams need to collaborate more and more visibility is required into what they do.
The vendor dilemma
De Menezes says: "Traditional software vendors have largely created their own challenge in this space because they've never had the flexible pricing and usage models that suited the market demand for agility. Large enterprise software vendors are usually looking to protect their revenue by offering perpetual licences with annual maintenance and support, while customers want as-a-service offerings, usage models, cloud models and short-term rental models."
Cripsey agrees. "We weren't agile in what we were putting out to market, we released annual versions of new software and couldn't adopt high speed changes. We were too monolithic and took too long to realise that we couldn't hold back development do an annual launch. Over the past five years there's been a major disconnect between how the software vendors operated and what customers needed."
The governance layer
Corporates face the challenge of standardising their testing environment, they need to adopt a DevOps philosophy and implement it across the organisation, and in the process eliminate the dozens of small ad hoc applications that people are using. However, while it's easy to get rid of the tools, the challenge lies in changing the behaviour of the people who have been using those tools. Any cultural change is difficult to implement and requires time and effort spent to get teams to change. The cultural change that comes into play with DevOps is so key to the whole process that if you don't culturally change the team's mindset, it won't succeed. DevOps is generally embraced by executives but can prove hard to implement because it's so disruptive, continues Simitci. "What's needed is a governance layer that helps manage the chaos and provides an integrated approach to tools across the DevOps cycle. So you don't have to change the way that people work, just the view that you have of their work."
Businesses need to implement a continuous DevOps lifecycle of constant monitoring and improvement of applications. There's enormous pressure to bring applications to market quickly, they no longer have to work perfectly from Day one, says De Menezes. However, faults need to be identified and rectified quickly.
"While businesses are aware that they need to have a DevOps philosophy of continual improvement, the majority of businesses have no idea what that should look like," he continues. "There's no cookie-cutter solution, every environment is completely different. I think the biggest mindshift is to realise that quality is everyone's responsibility, it's no longer a single team's problem. This is the only way that customers' skyrocketing expectations can be even halfway met."
While there is a plethora of application testing tools available, some open source, some enterprise grade, both have pros and cons. De Menezes says, "It's difficult to find a vendor that offers these testing tools as-a-service for short-term projects. Rather look for a common framework architecture that covers everything from code writing to delivery of the application online, if you find that, the tools become irrelevant. You can download whatever tools you like within certain parameters (ie it must be open and able to integrate) and use them through the governance layer, which enables integration and visibility."
Thus the tool becomes the enabler but the level above that is key. "Finally, enterprise-grade solutions have become flexible enough to meet customer requirements," says Cripsey.
However, there's still one challenge that remains, and that's bringing together the different elements within the organisation that are required to collaborate in the interests of delivering a business solution. Simitci says, "We're expecting people who've never worked together before to be part of the same team and this can create conflict within businesses that previously had very siloed roles and activities. Adoption of this new governance model will force new organisational collaboration that hasn't happened before and will create a new culture within that organisation of working together towards a common goal, instead of having vertically siloed teams each delivering different outputs. The barrier is no longer the tools, the technology or even the ability to provide a DevOps lifecycle. The true inhibitor is the ability to integrate the right kind of culture within the organisation."
De Menezes ends by saying, "All too often software vendors themselves are living this very journey while trying to implement better DevOps processes at their customers. We are definitely drinking our own champagne in this instance."
Share