Tag: mobile

  • Digital Transformation Strains Traditional IT

    Digital Transformation Strains Traditional IT

    It’s hard to believe, but it’s almost been 13 years since Nicholas G. Carr wrote his famous essay, “IT Doesn’t Matter.” In that column Carr argued that IT had become so pervasive in enterprises and so widely used that it had essentially become a commodity and was no longer useful as a tool for business differentiation.

    “Behind the change in thinking lies a simple assumption: that as IT’s potency and ubiquity have increased, so too has its strategic value. It’s a reasonable assumption, even an intuitive one. But it’s mistaken. What makes a resource truly strategic—what gives it the capacity to be the basis for a sustained competitive advantage—is not ubiquity but scarcity,” Carr wrote.

    If that sentiment was accurate then, and I wasn’t convinced it was at the time, it’s not accurate anymore. Today, how enterprises are building and implementing IT is a clear differentiator when it comes to delivering apps business users and customers need and want, built and designed in ways they want to interact, and delivered in a timely manner.

    According to a recent report published by Salesforce, “2016 State of IT,” IT leaders are focusing on mobile apps, migration to the cloud, as well as building adequate cybersecurity/incident response, customer-facing digital apps and productivity apps. The report found that 68  percent of respondents said that they are increasing their budgets on mobile apps, cloud and security. The lion’s share of respondents also plan to increase their budgets allocated to cybersecurity (63 percent) while 62 percent will spend more on employee productivity apps.

    The report survey, conducted at the end of 2015, is based on responses from 2,255 CIOs and IT leaders from within the United States, Canada, Brazil, Australia, Japan, France, the United Kingdom and Germany. One of the first things to leap out at me from the results is, based on my interviews with many enterprise users, this increased focus on mobile apps and employee productivity apps will certainly be welcome in most enterprises—mobile app backlogs are a problem in many organizations today, as we covered in “Make ‘Mobile First’ an Innovation Strategy,” “Mobile App Development Will Soon Grow More Enterprise-Focused,” and “For More Mobile Wins, Enterprises Must Find their MVPs.”

    As IT leadership had to do in every other transformative period (and cloud, mobile, data analytics are all transformative) such as the displacement of mainframes by PCs in the 1980s, the rise of the local area network and the arrival of the commercial web in the 1990s, IT is at the center of business strategy. CIOs and IT leadership need to make sure they get themselves out in front of these trends and align the services technologies they are delivering with what their users need. According to the report, this need for IT to drive innovation is forcing leadership to rethink their IT organizations. And, as a result, according to the “State of IT” report, to help address this, 60 percent of enterprises now have a relatively new position in the chief digital officer.

    Of course, as this push by enterprises continue, the competition for talent heats up. According to the “State of IT” report, the IT skills demand gap is widening: there just isn’t enough talent to go around. I expect this to grow worse as these enterprise budgets for mobile apps only continue to grow in the years ahead. And one-third of those surveyed in this report said that they are having a painful time keeping skills relevant with emerging trends in cloud, mobile and data analytics. Seventy­-two percent say talent/IT skills development and training will be absolutely critical or very important for their team in the next five to eight years.

    According to this eWeek story, “How the Skills Gap Is Threatening the Growth of App Economy,” while nearly 80 percent of respondents of a CA-sponsored study, “The Battle for Competitive Advantage in the App Economy,” said that becoming a “software-driven enterprise” is a top priority, the biggest challenge they have in realizing that goal is the skills shortage. The top four critical skills in that survey close resemble the findings in the “State of IT” survey: data science, collaboration, DevOps and APIs.

    The research firm Gartner predicts that by the end of 2017 demand for mobile app development services will grow no less than five times faster than the capacity of internal IT organizations’ deliver mobile apps. With steady mobile phone sales continuing to fuel demands for enterprise mobile apps, the result will be, according to Gartner analyst Adrian Leow, that enterprises will have a hard time rapidly developing, deploying and maintaining mobile apps to meet demand because of the scarcity of developers with good mobile coding and development skills.

    “Organizations increasingly find it difficult to be proactive against competitive pressures, which is resulting in their mobile apps becoming tactical, rather than strategic,” Leow said in this statement. “We’re seeing demand for mobile apps outstrip available development capacity, making quick creation of apps even more challenging.”

    IT leaders are also seeing demand outstrip supply of those with skills in IT security and data engineering and data science—and there’s no sign of a letup in any of these disciplines. Considering all of that, and what Carr write 13 years ago, parts of IT may very well have become commodities—especially at the infrastructure layer of the IT stack. Just don’t try and sell that view to anyone trying to clear their mobile app backlogs or get the most value out of their data today. They’re too busy trying to keep up and hopefully innovate a little to have time to listen.

  • Mobile-Disruptor Simgo Launches World’s First eSIM

    BARCELONA, Spain, Feb. 22, 2016 /PRNewswire/ — Mobile-disruptor startup, Simgo® today announced the availability of an SDK for it’s award winning virtual eSIM cloud-platform (vSIM™) for cellular devices. Simgo’s v-SIM SDK, simgoinside™ is the world’s first fully functioning e-SIM for smartphones, tablets, wearables, connected cars and the exponentially expanding universe of IoT.  The simgoinside™ SDK is available for implementation by manufacturers and OEMs today at no cost to partners. A v-SIM implementation enables remote provisioning and automated, dynamic instant connectivity to any available mobile network based on user-defined rules such as QoS and cost, among others.

    “We’re glad the GSMA recognized the need for an e-SIM and implicitly validated Simgo’s work in the space. Unfortunately, however, the specification does not go nearly far enough,” said Eyal Shmueli, co-founder and Chief Innovation Officer at Simgo. “The e-SIM does much for subscription management, but nothing for device manufacturers or subscribers, who need connectivity management. e-SIM simply gets rid of the need to swap out a physical card, but it doesn’t help any user, enterprise or otherwise, manage their connectivity based on real requirements like signal strength, or managing roaming, which are two major issues for connected cars for example.”

    “Our decision to make the v-SIM SDK available for integration for free reflects constant discussion within the industry to address the palpable frustration among enterprise IoT players that the industry is not keeping up with the momentous technological changes occurring in economy and culture,” said Avi Ben Shlush, co-founder and Chief Executive Officer at Simgo. “We know an open source, cloud-based solution is aggressive but we want to help catalyze evolution for businesses and consumers alike.”

    In other news at Mobile World Congress, Simgo announced that industry veteranMasahiro Inoue is joining the Simgo board of directors. Founding CEO of Yahoo!Japan, Inoue was formerly the Director of Softbank who was instrumental Softbank’s Vodaphone acquisition, taking it to the number 2 position behind NTT DoCoMo.

    Simgo will be demonstrating its award-winning vSIM™ product range at Mobile World Congress, Barcelona February 22-25, in Hall 5, Stand 5D81 and in the Intel Booth at 4YFN To schedule a meeting, click here or go tohttps://simgo.typeform.com/to/mqDHuD

    About Simgo
    Simgo® provides the world’s leading cloud-based virtual SIM (vSIM™) platform for cellular devices, developed from its patented and award-winning technology.  By moving SIM management to the cloud, Simgo is shifting the paradigms of the mobile world and opening doors to new and exciting opportunities for users, operators, service providers and device manufacturers. Simgo is a 2016 partner in the Intel® Ingenuity Partner Program, “a carefully selected group of startups, chosen for their vision, innovative technology, and potential to create transformative solutions and products.” Simgo was awarded the first place in theMobile Enterprise Innovation category of the 2015 CTIA MobITs awards.

    For more information, visit www.simgo-mobile.com

  • IT DevOps: One Size Does Not Fit All

    IT DevOps: One Size Does Not Fit All

    As absurd as this may seem, some in IT may be longing for the good old days of the mainframe. After all, the hulking machine, with its dumb terminals and thousands of punch cards, gave IT complete control. No citizen developers or business analysts allowed.

    Things got more complicated with distributed desktop computing and its different operating systems and requirements. Server-based web apps simplified things once again, but now mobile has made development more complex than ever. Instead of just updating the server, you also now have to update each mobile device—creating apps that work on each and getting changes out to the entire mobile population.

    What’s IT to do? Applied properly, DevOps can help.

    The Evolution of DevOps

    Coming on the heels of agile development—a term first coined in 2001—is DevOps, which was first popularized in Belgium in 2009. Today, 15 years into agile development and six years into DevOps, it is becoming clear that these intertwined terms are quite broad, encompassing attitude and approach, platforms, tools and solutions. Agile development, with its Scrum meetings and quick turnaround cycles, did speed development but made deployment more difficult, because many organizations just couldn’t support fast cycle deployment.

    DevOps, with its platforms, tools and practices emphasizing collaboration between IT and development, targets application delivery with continuous testing, ongoing feature development and ongoing maintenance to deliver apps faster. While the intention is well and good, the DevOps process must be task-specific to succeed.

    Today’s development environments can be broken down into three categories: low-code, deployment-centric apps and, in a class by itself, mobile. Delivering apps in these three environments involves a broad range of skills and tools. Therefore, the approach and degree to which DevOps is utilized must vary as well—from virtually no DevOps in low-code environments to extended DevOps in mobile.

    Low-Code = Zero Ops

    In cloud-based, application performance-as-a-service (aPaaS), low-code environments, DevOps can take a back seat. With the vendor managing, maintaining and controlling the deployment environment, the citizen developer or business analyst is empowered to work on GUI development and other features and functions with little involvement from IT or development. In these environments, power users can easily push out low-code apps. A strong DevOps presence here is not necessary because the separate environments typically required to propagate apps does not exist. The business analyst simply makes the changes and pushes them through to production.

    Here, IT is best utilized as gatekeepers, getting involved only when needed. We characterize these environments as zero ops—the less DevOps the better. This leaves business users, IT and development free to focus on their strategic areas and core competencies, funneling resources appropriately and enhancing productivity across the board.

    Deployment-Centric = Controlled Ops

    High-transaction, highly scalable, business-critical global apps fall into the deployment-centric category. The goal of DevOps in these code-intensive environments is to free developers from deployment issues, enabling them to focus on their key competency of writing code. Well-executed DevOps can effectively move apps from development to deployment, enabling tight collaboration between development and IT. In this environment, a well-managed DevOps process can make it easy for the DevOps team to deploy the apps and to manage the deployment moving forward, scaling apps automatically with rules that scale automatically based on usage.

    That is why we characterize DevOps in these environments as controlled ops, a collaboration tightly controlled by development and IT.

    Mobile = Extended Ops

    From development to deployment, maintenance, monitoring and analysis, mobile has introduced new levels of complexity to application delivery. Developers have iOS, Windows and Android to deal with, not to mention multiple versions within those environments. Then there is the development environment itself—web, native or hybrid. Compounding it further are the devices—countless phones and tablets. And deployment options—public app stores, private app stores, file-sharing services. Finally, the end user is engaging the device in ways never before imagined, placing the need to build responsive and compelling user experiences front and center.

    This environment calls for extended ops—a highly collaborative environment where development, deployment, maintenance, support and business stakeholders are all integral to an app’s success. In mobile, everyone needs to have a place at the DevOps table, as mobile apps are literally iterative apps—constantly on the move, morphing and changing, driven primarily by end-user feedback. The ability to make seamless updates and user-driven changes at record speed can spell an app’s success or failure. The collaboration, platforms and tools DevOps offers in this environment have never been so critical, as business users now must be involved in the design and development of the app and in analyzing how the app is used, which will dictate changes moving forward. Successful, extended ops welcomes business users, but does not involve them in the DevOps process itself—that’s for IT and development.

    In Summary

    DevOps can have an impact on the entire application delivery cycle. From improving deployment frequency—which can lead to faster time-to-market—to shortening lead times for new releases with lower failure rates, the goal of DevOps is to maximize the predictability, efficiency, security and maintainability of the simplest mobile app to the most complex transactional system. The key to successful DevOps is applying the right level of collaboration and employing the right tools to ensure that DevOps improves quality and productivity rather than hinders it.

    About the Author/Mark Troester

    image001Mark Troester is the Vice President of Solutions Marketing at Progress Software. Mark has extensive experience in bringing application development and data integration products to market. Mark previously led product marketing efforts at Sonatype, SAS and Progress DataDirect. Before moving into marketing, Mark worked as a developer and developer manager for start-ups and enterprises alike.
    LinkedIn Google+

  • Make ‘Mobile First’ an Innovation Strategy

    Make ‘Mobile First’ an Innovation Strategy

    The call for organizations to be “mobile first” in application development has been so heavily embraced by enterprises that today mobile first has become table stakes. Being mobile first is no longer cutting edge but merely keeping pace with the enterprise pack. And a big pack it has become: According to ABI Research, revenues generated by the enterprise mobile market are growing at twice the rate as consumer apps and will reach $340 billion by 2017.

    With that size of a market in place, and nearly every employee having as many as three mobile devices, and every enterprise cranking out mobile apps as quickly as they can, how are organizations supposed to leverage that mobile infrastructure?

    Here are a few ideas how:

    Capture the continuous, mobile data inputs that matter

    As readers of devopsy.kinsta.cloud are quite aware, the enterprise has evolved into a continuously integrated, continuous developed and continuously deployed software and data factory. If you’re reading this site, you are aware of the tremendous benefits of DevOps, as well as the the changes containerization and microservices are bringing to IT.

    But the continuous nature of the modern enterprise isn’t just about applications, especially in today’s mobile environment. It’s also about continuous data being captured by users and devices. To successfully innovate and compete today, IT leaders must take advantage of all of the real-time, continuous data inputs that are rolling in from their users’ mobile devices and, increasingly, IoT-connected enterprise devices. This data is critical when it comes to understanding customer trends, supply chain health, regional differences in demand, emergencies as they arise, and many other factors regarding business and IT health.

    This means IT leaders must look for ways to capture, store and analyze these continuous mobile data inputs—and they better start now while the task is still manageable. According to IDC, there are already 200 billion computerized things connected to the Internet, and in four years there will be more than 50 billion networked sensors. The amount of data—and the importance of this data—is astounding.

    Leverage citizen developers to meet mobile app demand

    Enterprise mobile app backlogs continue to be the bane of enterprise mobile efforts. As covered in Clearing through the app backlog clutter, 85 percent of enterprises have an app backlog, and about half of those that do lag behind 10 to 20 apps in their pipelines. These app backlogs are costing enterprises in lost productivity and revenue.

    Where should CIOs and IT leaders turn to clear these backlogs? To their citizen developers, of course. Citizen developers are not without their own risks, such as with cybersecurity and regulatory compliance. But through proper awareness training and monitoring, these risks can be mitigated.

    And the benefits of working with citizen developers are too great to ignore.

    For one, citizen developers can help free the mobile app backlog as well as free the core development team for more mission-critical apps. If the business needs apps that won’t be connected to sensitive systems, or managing sensitive or regulated data, let these business developers build apps on their own, if they are so inclined.

    And the data indicates that more and more are, in fact, so inclined: According to an Intuit QuickBase study, “State of Citizen Development Report,” of the 148 professionals surveyed who identified either as citizen developers or as IT pros who support a citizen developer, 62 percent reported being able to develop apps in less than two weeks.

    Citizen developers can also be encouraged through training to program with code-free development platforms or some of the high programming and scripting languages. This way, when business users find themselves not as effective as they want because of the lack of an app, they can build the app on their own and not have to worry about IT bottlenecks.

    Deep dive into mobile micromoments

    Another way to drive innovation through mobile is to ensure development teams are developing an optimized mobile experience. That means taking advantage of micromoments. Today, workers don’t sit and focus on work as much as they used to. Nope. These days, they are updating data on their phones while scurrying between meetings, standing in line or doing whatever it is that they happen to be doing in-between primary tasks.

    According to an article on The VAR Guy titled, “Survey: Poor User Experience Leading Cause of Enterprise App Failure,” a survey of more than 340 respondents reported that 50 percent said their projects didn’t move forward in the enterprise because of user interface problems. Such UI problems were also cited as one of the greatest reasons for app delays.

    Mobile applications have to be designed with this use in mind. Not only do apps have to be designed with the smaller form factor in mind, but they also must be designed with contexts of the moments in mind. That means taking into account features of the phone such as location, voice and ability to insert photos or video. Developers need to develop specifically for both the form factor and the context in which users engage these devices. Only then will more benefits of mobile be reaped.

    Embrace an IoT platform

    Most of the data generated by IoT will be managed by IoT platforms, or IoT brokers. In 2015, the industry witnessed a lot of action in both the independent IoT players as well as large cloud providers.

    According to ReportLinker, IoT platforms, hardware, services and software will become a multitrillion market. “Revenue generated in 2015 [by IoT] was approximately $330 billion and is projected to reach $453 billion by 2020 with a CAGR of 6.2%,” the firm stated in this release.

    The large enterprise software players didn’t stand still when it came to IoT, either. Amazon, IBM, Microsoft and Salesforce all jumped into the IoT fray with their platform offerings. And while 2015 was the year for technology platforms to come to market, 2016 will be the year IT leaders prepare their organizations to take advantage of the data, insights and control that IoT will provide their organizations in the years ahead.

    Provide continuous mobile insights to users wherever

    When it comes to mobile data and big data analytics, it’s easy to forget that mobile devices are more than mobile data inputs—workers need them to provide valuable, contextual insight as well. To make the most of all of the data being captured from mobile apps and IoT platforms, it’s crucial that data be accessible anywhere and be displayed in ways that make sense to your employees and users.

    To succeed here, it’s important that big data insights don’t languish in big, isolated databases. Enterprise data needs to be accessible on every type of device, including mobile.

  • Five often expressed obstacles to enterprise IT innovation

    Five often expressed obstacles to enterprise IT innovation

    Business leaders know, for their business to succeed in the years ahead, that their IT and developer teams need to innovate. But surveys show that too often the IT teams may not be able to deliver the innovative value that the business seeks. Have a look out our recent Q&A, The IT mandate: Be a catalyst of business innovation for some more insight on the IT and business innovation gap. The fact is that technology and developer teams can’t do it on their own, they need to operate in an environment that enables innovation. In speaking with CIOs, developers, and others close to the process of creating value with IT a number of obstacles continuously surface. And these obstacles are holding their development efforts back.

    These obstacles include the tight collaboration with development and operations teams, the failure to actually embrace Shadow IT for what it actually is, staying stuck in single mode IT, and oversights in how they are developing mobile applications.

    Here they are:

    Obstacle Number 1: They don’t effectively unleash the power of their developers. DevOps teams are known to grind through technical debt and when they manage to hit on all cylinders they also have very short application backlogs. One way to keep such app backlogs short is to focus on the Minimum Viable Product (MVP). Because the MVP is an application that is, initially, focused only on what it takes to get the job done, and no less or more, developers don’t get bogged down overdeveloping apps that won’t get used. To be clear, MVP doesn’t mean shoddy app, rather it means the minimum app to be productive at the task. With this Spartan approach, development teams can invest no more than is needed into an app, release it into production and see how enthusiastically (or not) it is embraced by the user base. This enables development teams to push apps forward with as little risk and investment as necessary. And then either dig deeper into that app, or move on to another.

    What does that have to do with innovation? Plenty if you consider the amount of time saved from over-developing applications that wont be used and investing that time and effort elsewhere, perhaps apps that will provide value to the organization.

    Obstacle Number 2: They don’t embrace shadow IT. Rather than embrace Shadow IT, many organizations shun the notion of users choosing the tools and technology they need to get their job done. But end users and employees are turning to cloud services and bringing their own devices because these are the devices and services that they know they enjoy to use and they can use to effectively do their jobs. That makes for more productive and happier workers. Certainly not just any old rogue service and device can be used, but the enterprise can watch and vet the services that are safe or find ways to make them safe. A good place to look for this is the Cloud Security Alliance’s Security Guidance for Critical Areas of Mobile Computing.

    Obstacle Number 3: They don’t bimodal. By not embracing two-speed or bimodal IT, enterprises have a harder time allotting resources to strategic development and IT efforts. In bimodal IT there are two modes, one mode is focused on quickly delivering the applications the enterprise most needs to compete and be effective while the other mode is focused on the infrastructure services and API development and management.

    A good overview on bimodal IT can be found here in our post Bimodal IT and Remodeling Traditional IT for Greater Agility.

    Obstacle Number 4: There exists an average to poor business to technology interface in the organization. In too many organizations there is a lot of collaboration within the technology groups, such as operations and developers, but not enough interfacing with the business teams. For better outcomes, there needs to be tighter collaboration between DevOps and the business through continuous feedback on current and future objectives. This way DevOps teams know what the business priorities are and can develop to them more effectively.

    Obstacle number 5: They aren’t focused on the context within mobile moments. The world of IT has gone mobile and will someday go wearable. This is more than just a mere form factor trade; it is creating a profound change in the way we interact with our apps. When we sit down to work on a laptop, we are usually settling in for a nice stretch of work time. However, when it comes to phones and wearables, we are usually working in short instances. We are sending a text, answering one email, or capturing one or two new data points about a client for entry into the CRM app. Developers need to focus on providing users apps that work in the same way too. That is they need to develop apps that provide users the data they need based on short device interactions and hopefully context of what they’re doing. If the user were at a clients’ office, for instance, and the rep launces the CRM app, it’d be ideal if that customer profile launched by default with the app. If the user is involved in a certain workflow, other items that are commonly taken care of at the same time would also ideally be suggested.

    While these obstacles may sound simple, they can be quite transformative to the way your business-technology teams will develop, collaborate with the business, and hopefully provide more innovative services.

  • Mobile developer trends for CI and the cloud

    Mobile developer trends for CI and the cloud

    Mobile developers understand the rising importance of continuous integration (CI). The promise of CI is to speed up the overall velocity of the app team by building and testing every single code change. This environment of rapid change means that code integration issues are caught early, and testers and beta users can provide feedback on these changes as quickly as possible. As CI has become commonplace for app development teams, and many are moving their CI infrastructure to the cloud, the importance of build and regression test automation has grown.

    To that end, we thought it would be important to generate a research report by examining survey data from more than 500 mobile app developers and benchmarked usage data from more than 250,000 automated builds, tests and releases on the Ship.io platform. This Mobile Metrics Benchmark Report shares insights and trends around the Continuous Integration (CI) landscape in regards to mobile app development. Key areas of focus for the report include CI adoption across major mobile operating systems (iOS, Android), frequency of testing, releasing and checking code, app build times and frequency, and common build failure reasons across geographies around the world.

    v3-Ship_io-Infographic-FINAL-8_3_15-01-580x1024

     

    OVERALL CI ADOPTION
    Of app teams surveyed, the majority are leveraging CI. Those not leveraging CI are often building only on-demand when they want to test a build, or are building with a simple regularly scheduled nightly or weekly build scheduler. Of teams that are leveraging CI processes, the majority of them are running some form of test automation on each build. Here’s a breakout:

    • Less than 5 per week: 15%
    • Between 5 and 25 per week: 33%
    • Between 25-50 per week: 33%
    •  More than 50 per week: 19%
    • No, not doing CI right now: 37%
    • Yes, doing CI builds and tests: 35%
    • Yes, doing CI builds: 28%

    THE CLOUD CI ADOPTION LANDSCAPE: Cloud CI Adoption: iOS vs Android
    Many app teams have adopted Continuous Integration as part of their engineering processes. Some teams have set up CI as an on-premise service, but many are moving this to the cloud for reasons such as cost savings, focus, and reliability of the CI system. An oft-cited reason for moving to cloud CI systems managed by others is the complexity and cost of keeping up with all the changes in the iOS and Android build and test ecosystem.

    Of all developers surveyed with an interest in Cloud CI, but not necessarily using CI systems today, the majority (50%) are only focused on iOS—ignoring Android altogether. Other developers are focused on both platforms, with a small minority focusing only on Android.

    PUBLIC vs. PRIVATE APPS
    Developers with an interest in CI are overwhelmingly building apps for Google Play and the App Store. Only a small fraction of these developers are building apps for internal use, or with a limited number of customers. Many of these internal-facing app teams have smaller app teams and longer release cycles, presumably diminishing their need and interest in continuous integration systems.

    WHY BUILDS BREAK AND BUILD SPEED METRICS
    As many app teams have moved to a continuous integration (CI) model for development, they produce many more builds. This increase in build frequency means that the time spent building is far more significant, and broken builds can randomize and delay product progress. The data shows that the majority of build breaks are avoidable, and the time spent building apps is low, but iOS builds are about twice as fast on average versus Android.

    Analyzing the source of build breaks across both iOS and Android reveals that there is a very long tail of build breaks as many engineers would suspect. Builds often break due to of various developer code syntax issues, but several build breaks account for the vast majority (74%) of all breaks in cloud CI builds:

    • Missing File or Directory: Developers often forget to check dependencies and new files into the code repository.
    • Lint Errors: When ‘lint’ is enabled on a build, it often catches common programming errors.
    • Unit Tests: Many apps have regression test automation at the unit level. These tests fail during the build process, catching either changes in the app, or regressions.
    • Linking: Builds often fail at link time because a referenced 3rd party library wasn’t added to the dependencies list, or project dependencies were not updated.
    • Code Signing: The process of signing apps is still error prone. From missing signature files, or differences in debug versus release build configurations, code signing causes many CI headaches.

    The good news is that most all of these build breaks could be caught by developers having a separate ‘clean’ enlistment and building and running lint locally. Even more breaks would likely be prevented if developers simply executed unit tests before submitting new code. Barring that, cloud CI systems make it easy to catch all these issues, and mark the build as failed until developers resolve the break.

    BUILD TIMES: iOS vs. ANDROID
    When app builds break the team is often blocked and waiting for a new build. Build times are now a critical path for app teams. Analysis of iOS versus Android build times reveals that although iOS app build times are about twice as fast on average, the build times are still reasonably short at 2 minutes and 4 minutes on average, respectively. A deeper look into the build time data shows that very few app build times, regardless of platform, exceed 30 minutes. The majority of app build times are less than one minute. An interesting aspect of build times is the fact that more Android than iOS app builds complete in less than 2 minutes. But of all large/complex app builds (longer than 2 minutes), iOS app build times are generally faster by a factor of 2.

    COMMIT FREQUENCY OF IOS vs. ANDROID CLOUD CI TEAMS
    Of the top 40 apps with the most frequent commits in the study data, 67% of them were iOS Apps. It is worth noting that the study data had builds from app teams that built both Android and iOS versions of their apps. iOS developers seem to be committing code more frequently and adopting the CI model of small, continuous commits.

    COMMIT FREQUENCIES: IOS vs. ANDROID
    iOS developers make far more revisions than Android developers. Across the spectrum of commit frequency, iOS developers, on average, are making twice as many commits as Android developers. The majority of apps have one commit per week, or fewer. Of those that are very active, defined as committing code more than 3 times per week, about two thirds of those developers are working on iOS. The aberration seen where Android developers are building 6 times a week, is due to a single app vendor with many apps, all sharing a common code base with many Android apps (with commit frequencies at 6 times per week). In general, iOS developers are about twice as likely to make more than 3 commits per week versus their Android counterparts. In total, iOS developers, on average, are making twice as many commits as Android developers.

    TOP PRIORITIES INCLUDE FASTER RELEASES
    Of all the things app teams were looking to prioritize in the coming year, faster release and update frequencies (41%) was a close second only to improving overall app performance at 48%. Teams are quickly migrating to Cloud CI systems as a way to accelerate their overall velocity. Cloud CI enables teams to focus their time and money on other priorities such as performance and security.

    WHY NOT CI?
    The reasons why teams haven’t adopted CI vary widely. 49% are interested and plan to move to CI eventually but haven’t because of prioritization. Some teams believe they are too small to benefit from the value of CI as their team only has one or two people working on the builds, or they have so few code revisions that they prefer to deal with builds manually. A minority of app teams are concerned with the cost in money or time to move to a CI system.

    Why Deverlopers are Not Adopting CI

    CONCLUSION
    These Ship.io study results show that the world of CI for app teams is changing quickly and varies between iOS and Android app teams. Knowing the macro-level trends and learning from them, can greatly impact your app teams efficiency. As app teams accelerate due to CI adoption and agile practices, teams are often spending an inordinate amount of time focusing on their local and custom build and test infrastructure. Those app teams that have moved to the cloud are saving money and time and focusing more on their app design and implementation.

    • CI Adoption: Cloud CI adoption is on the rise, especially in the iOS community. iOS developers are more aggressively adopting cloud CI than Android developers. The number of teams adopting Cloud CI is doubling every 6 months.
    • Commit Frequency: There is a wide range of commit frequencies across iOS and Android. iOS app developers generally have twice as many commits as Android developers. The commit frequency and the number of builds range from a high of around 16 per day, to a low of once every other week.
    • Source Control Popularity: Two cloud source control repositories represent almost all cloud CI systems: GitHub and Bitbucket. The momentum is strong with Bitbucket which saw its share of usage double in just the past 4 months. Android users seem are more aggressively moving to Bitbucket, but iOS developers aren’t far behind.
    • Build Breaks: Several common issues account for the majority of build breaks, but there is a very long tail of build break reasons. The good news is that many of these are avoidable.
    • Build Time: Build times on iOS and Android are similar and range from mere seconds to a high of 40+ minutes for apps with larger code bases and dependencies.

    Download the full report here

    shipIO-report

     

     

     

     

    About the Author/Prathap Dendi

    leadership-prathap-dendiPrathap is GM for Ship.io, and VP Business Development for Electric Cloud. He drives strategic partnerships that help us deliver broader solutions to our customers. Electric Cloud has forged strategic partnerships with companies providing industry-leading tools and services in order to deliver software production automation to our customers.

  • DevOps Chat: Rosalind Radcliffe, Mobile to Mainframe DevOps for Dummies

    DevOps Chat: Rosalind Radcliffe, Mobile to Mainframe DevOps for Dummies

    mtmdummies_large

    I recently had a chance to sit down with IBM Distinguished Engineer Rosalind Radcliffe about her new book, Mobile to Mainframe DevOps for Dummies. The book is actually quite a bit deeper than your usual “for Dummies” book and an excellent read. Of course you would expect as much coming from Rosalind who has quite a list of well deserved accomplishments and accolades on her CV.

    Saleem Padani of IBM has a good post up on LinkedIn announcing the book as well that you may want to check out.

    FYI, we will be doing more DevOps Chats in the future. If you would like to be a guest on a future episode please contact editor@devops.com

    Above is an embedded audio player to listen to the interview of Rosalind. Below that is the transcript if you would like to follow along or just skip the audio and read the interview. You can download the free e-book copy now by visiting https://ibm.biz/m2mdevops

     

    Audio Transcript

    Alan: Hi, everyone, this is Alan Shimel, Editor in Chief of devopsy.kinsta.cloud, and we’re kicking off a new feature here at devopsy.kinsta.cloud—DevOps Chats. Each episode will feature me speaking with a thought leader around a particular topic of devops.

    Kicking off our series today with a very special guest, Rosalind Radcliffe of IBM, and we’re gonna be talking to Rosalind about a new book which she has just offered called Mobile to Mainframe: DevOps for Dummies. Rosalind, welcome to devopsy.kinsta.cloud.

    Rosalind: Thank you.

    Alan: Okay, let me briefly give our listeners a little background on Rosalind, and Rosalind, I don’t mean to embarrass you, but you have quite a résumé. Rosalind is a Distinguished Engineer in IBM. She’s Chief Architect for CLM and DevOps, and she is responsible now for driving devops for multi-platform architecture. This includes System z and Power Systems. In addition, she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions, and this includes both UrbanCode Deploy and Rational Team Concert’s support for standard mainframe development activities.

    Beyond that, Rosalind is a member of the IBM Academy of Technology and a master inventor. Prior to her current development related responsibilities, she has been responsible for IBM’s SOA Management Strategy and Services, responsible for deploying Systems Management solutions, and she started with ISPF development.

    Rosalind, I hope I didn’t embarrass you too much, but once again, welcome to devopsy.kinsta.cloud, and congratulations on this great new addition to the DevOps for Dummies series, Mobile to Mainframe DevOps for Dummies.

    Let’s start today’s chat, if you can share with our audience a bit more about you and where you are in your career.

    Rosalind: Thank you, and I’m looking forward to this chat. So, a little history on why I wanted to write the DevOps for Dummies book. I started in IBM 28 years ago in ISPF development, as you mentioned, and I’ve been in different roles and different responsibilities along the way, including spending a good amount of time in the Systems Management organization, responsible for actually doing operations like tasks and deploying our Systems Management solutions for clients.

    I’ve also spent a number of years in the application development space, providing and building application development tools. And so, as this developed over the years, working in operations, I used to blame development, and then when I moved to development, it was, “Oh, I guess I can’t blame operations.” So it’s deemed appropriate that I would move into this devops space of trying to bring these teams together.

    In looking out at the industry today, I see that there are lots of questions, especially in the mainframe space, about, “How does this devops really apply to that environment, and with all the drive for mobile and mainframe together, how do we really make this play as an environment?” And so, that’s how I got here and why I wanted to write this wonderful book.

    Alan: So, let’s dig in quickly to the book. You know, I think everyone in our audience is familiar with the “For Dummies”, if you will, franchise, and some of them can be rather fluffy, some are better than others, obviously, depending on authors and so forth. My initial reaction when I read it, Mobile to Mainframe DevOps for Dummies was, “Wow, that’s a pretty heavy topic for a For Dummies book.” Why write this book in the first place and why now?

    Rosalind: Well, I think now is a perfect time, with the industry evolving, with the mobile frontier and everybody focusing on mobile, and with mainframes truly being our systems of record. So, everybody needs to connect mobile to mainframe, and if we look at the development environment, most mainframe development shops look remarkably like they did when I started 28 years ago, and that’s not necessarily a good thing.

    So what I wanted to do was help explain to executives, senior leaders, and anyone in the industry, how mobile and mainframe play together and, in using the devops transformation helping them work together, they can get more value out of the systems that they currently have.

    Alan: Absolutely. And just so we can mention, of course, Rosalind, the book is available for download, we’ll have links on it up on devopsy.kinsta.cloud. But, as I mentioned, it’s not a fluffy book—there’s a lot of great content here. I can tell how much time and effort you put into this thing.

    But, give our audience a sense—how much, how big an effort was it for you?

    Rosalind: It was a significant amount of time in writing. I spent a lot of time on plane flights back and forth to Europe, and that gives you a lot of time when you can’t do anything else, and so I spent a significant amount of that time writing. It’s a relatively short book, it’s only 70-something pages, so it’s not as long as a very long book, but it did give me the opportunity to hopefully give some background, explain more about the current environment, and give people an insight as to what I’ve been seeing with clients and help them move forward.

    After you write it, then you have to edit it, and I have to thank the many people that helped me work on this and help provide contributions and pieces of the document, because they helped me put this together, and helped me do a lot of editing as well to make sure that it was complete in the environment.

    Alan: Sure. I mean, I’ve been lucky enough to have a chance to see a pre-publication version of it, and I do think—you’re right, it is only 70-some odd pages, but it’s pretty in depth. But it really benefits from the sort of, the For Dummies kind of franchise—you know, the icons they use to help you focus in on what’s really important and giving you Cliffs’ Notes version if you wanted to not read every word. You used the format very well, and I think people will get a lot out of the book.

    Let’s dive in a little bit, though, into some of the key points that you’ve brought up in the book. You know, just picking some random ones that I thought were important—in chapter 3, for instance, you speak about why we need to understand why devops is so critical for mainframe environments. And we need to start with the dev side.

    But devops is about breaking down silos, it is about cross functions—and nowhere, in my mind anyway, nowhere are these silos more separated than between the mainframe teams, like you said, haven’t changed sometimes in 28 years when you started, and the distributor mobile development teams, who are today all about cloud and virtualization and instant up and instant down.

    Can you elaborate a little bit more on this point for our audience?

    Rosalind: Yeah, I’ll be happy to. This is one of the key points as to why devops matters more than ever now in the mainframe space—this transition to mobile, this transition to systems of engagement and their dynamic changes, their need for speed, and the need to access these back end systems of record. So now is the time for us to evolve the environment, the mainframe development environment, to modern technologies and modern tools to allow these teams to actually work together.

    There is absolutely no reason that mainframe environments need to do development the same old way. They don’t need to be done using waterfall development practices. There’s no reason not to apply the same agile and lean IT practices across the development organization from mobile to mainframe, and using the same tools and the same capabilities so these teams can work together, they can share information, they know what each other’s doing, and you can break down those silos.

    One other reason those silos are there is, you know, if your mainframe development team is using ISPF, I’m not sure those mobile guys using X code even want to look at a green screen. So this has to change. The perfect time—bring these teams together, use modern development practices, use modern tools, and this allows the silos to be broken down, allows the teams to work more efficiently together, and helps deal with this variable speed IT issue that we have. Mobile needs to move fast. Those systems of engagement need to be moving.

    But the back end systems of record need to be able to define standard APIs. They need to provide those services that the front end needs, and they need to do it fast enough—so they need to do it at the speed of business, and devops helps them do that.

    Alan: Excellent. And so, Rosalind, you actually touched on something here, and it’s this variable speed IT—variable speed devops, I’ve heard some analysts call it a bimodal  IT—and it, I mean, you nailed it right on the head. These mobile development teams that are running at the speed of today’s business, tearing it up, putting it up, tearing it down, putting it back up—changing, changing, changing thousands of hundreds of times a day, even, in some cases.

    We can’t expect the mainframe systems of record to perhaps move at that pace, but there’s no reason they can’t move faster, especially using modern tools, modern development environments, though I still find something comforting about a green screen. [Laughter]

    But, that being said, you know, this was the subject of a whole series of webinars we did here on devopsy.kinsta.cloud on variable speed IT and variable speed DevOps. Can you help our audience understand why it’s so critical for mainframe environments to embrace devops and why now, more than ever, now is the time?

    Rosalind: Yes, so with this variable speed IT, and as we talk about it, it’s not that the back end is slower because mainframe development is slower, it’s that, in variable speed IT, you need to move at the speed of business, and if you define services as your back end systems of record, those don’t need to move as fast.

    What we need is to define those as services so the front end system can use them, so these systems of engagement can call back into the function. So the need to define these services based on the existing legacy code means development teams need to be able to respond at the speed of business. They need to be able to move faster. And the old ways of doing things—you know, making a change and testing it for three months—just isn’t gonna work. We need to apply the principles of automation, automated testing, virtual services, and interface testing, and bring all of those concepts to allow you to build those services based on the existing business function into the environment so that they can then be called by the systems of engagement.

    Companies have significant assets sitting on the mainframe systems. Mainframes aren’t going away. They’re gonna be here forever. They provide the qualities of service needed for large scale transaction performance systems. And so, with mobile, large scale transaction performance systems—that’s perfect. Mobile backed with mainframe is a perfect environment. And companies with the assets that they’ve built up, if they can service-ify them fast enough, they can provide disruptive technology today.

    And that’s what the companies need to do. They need to take advantage of the assets they have, providing services using the new development practices, and then it all fits together and they get the business value at the speed they need to. And you know, I helped build ISPF, so I do like that green screen, too—but it’s not really the right development platform for developers today.

    Alan: Yeah. But what about—look, you know, people make fun of COBOL developers, but there’s still a lot of jobs out there for COBOL developers.

    What about the shortage of experienced mainframe IT skills in the marketplace, Rosalind?

    Rosalind: Yeah, so that’s one of the points I make in the book. Developers can write any language. You know, get a good developer, they can write COBOL—and there’s nothing wrong with COBOL. COBOL serves its purpose. PL/I serves its purpose. And some people will cringe as I say this—Assembler serves its purpose. But you know, I’m not gonna write it using ISPF.

    If I’m a kid coming out of college and you give me a modern IDE that has all of the language syntax in it, it has code rules, it has the ability to build unit tests for me—I can write COBOL. Not a problem. It’s the—give me an ISPF screen, and I don’t even know how to use it, much less how to do COBOL.

    Alan: Understood, understood. Let me—we’re running low on time, so let me turn to some other questions I had prepared, if it’s okay. In the book, you talked about some of the best practices—devops best practices on System z which, for our listeners who may not be IBM aware, System z is the IBM mainframe platform.

    Rosalind: Correct.

    Alan: And there are several good ones that you have highlighted in the book. Are there specific devops practices that you would recommend for System z to get started down the path of continuous delivery, which some people think is the ultimate aim of devops, or the ultimate goal?

    Rosalind: Yeah, so there are a number of different practices, but a few call out based on the way many mainframe organizations are working today, and it has to do with where they are today. How do they improve the process from where they are to get into more continuous delivery practices?

    And before someone says something, I’m gonna say—continuous delivery does not necessarily imply continuously delivering into production. It means continuous delivery into a pre-production, et cetera, environment. You may still need to stage those based on an outage window, especially for systems of record, because you can’t afford to have a transaction change mid-flight.

    So there are some—you know, continuous delivery within reason. But if we think about those things, one of the key practice is modern development tools to break down the silos. And one of the others that is absolutely critical is automated testing. There is no way to get to continuous delivery without automating testing, and since you’re building services out of your back end systems, services are a perfect thing to use automated testing against.

    So, building up automated testing based on the service interface, being able to test the function without having to have users go in and test the business function—just run a bunch of automated tasks and make sure you’re picking the right automated task based on the code that you’re changing, but automated testing is probably the biggest change that is needed for mainframe environments and, in many ways, the most valuable. We look at many shops and they’re spending months running lots and lots and lots of manual tests that they hope will find the problems.

    Alan: Got it, got it. Rosalind, we only have time for maybe another question or two, but I have one very IBM specific one, one a little bit more general.

    So recently, the new z13 launch really put the mainframe front and center as the core element for IT infrastructure.  Is this the rebirth of the mainframe? How do we see this new mainframe fitting into this seemingly ever changing IT landscape? More importantly, what do existing mainframe clients do to prepare for this new age of mobile to mainframe?

    Rosalind: So, the z13 has lots of additional capability and functions along with the updated compilers to increase the speed to allow you to provide more function faster, COBOL improvements using the new system hardware, Java improvements to be able to do more Java development on the mainframe, as well as significant memory availability changes.

    So, with the combination of the system, you can look at it as the best Linux environment that you can use for your cloud environment, so you can have—use Linux on System z to provide your Linux environment for your front end applications, and then, looking at z/OS, you can start to take advantage of this new memory that’s available to increase and improve your performance from a caching standpoint, numerous other things from a performance standpoint with the new compilers, and the mobile connectivity into the system. If we think about the fact that that could drive huge numbers of transactions—could drive huge numbers of transactions—we get the mainframe as the perfect platform to handle that variable load.

    So you never know—you know, I guess if you’re a retailer you know if it’s Thanksgiving or near Christmas it spikes, but many times, you don’t know where the spike’s gonna come, so it’s important to have that capacity on demand, to have that variability, and so the system plays very well.

    I think there are a lot of clients and a lot of organizations that are taking a new look at the mainframe of the latest z13 because of its capability, because of its enhancements from a memory standpoint, and because they think—you know, reality. People are realizing the mainframe is not going anywhere, and it really is the best platform for those high transaction systems and allows you to consolidate things together in a Linux platform. So it’s a great advantage that customers were already using we they have, and it’s something other customers are looking at to do, “You know, I can take advantage of that as well.”

    Alan: Okay. Rosalind, again—I’m sorry to keep saying this, but I’m trying to keep it short for our listeners, and relevant, but there’s just so much here. So you’re constantly out talking to clients that utilizing mainframes, and kind of living this devops and mobile to mainframe way of doing business—can you give me two or three quick examples of companies that are, that you think are doing it right?

    Rosalind: So, if we look at the industry and we look at the publicly available references, Nationwide is one of them that’s been out talking and describing their devops transformation and how they’re exploiting the fact that they’ve brought their teams together to provide value faster in the environment. We can look at Fidelity, who’s talked about their improved deployment capability and their improvements overall in their environment. Or, one of the examples I like that Walmart and their example of using services on the mainframe to actually provide infrastructure services to all their distributed applications from a caching service.

    And so there are numbers of good examples that talk externally, and then there are a whole bunch more examples who consider their transformation to devops a business advantage. They see that, by transforming to devops, they’re getting a leg up on their competition, and so they’re not as willing to let us use their names—but there are lots of wonderful examples of people who have transitioned and who are getting the value out of it, including IBM itself. We have numbers of examples that we provide to show our development process significantly improving and breaking down the silos within our own organizations and improving our ability to deliver.

    Alan: Excellent. Rosalind, I think this was very helpful, as is the book—a great guide for, as you mentioned earlier, both executive managers and practitioners.

    What about you, Rosalind? You’ve had such a successful and storied career—what’s next? What’s next for Rosalind?

    Rosalind: Yeah, so the next thing next week, actually, I’ll share. So, next week, we have one of the major user conferences or the major user conference happening in Orlando. And, as part of SHARE, obviously, we talk about mainframes and development activity as well as lots of different topics, and I’m looking forward to that in particular, because we’re doing a series on mainframe and mobile. More specifically, we’re doing a discussion about hooking Bluemix, our development app platform as a service along with IBM devops services to the back ends, and helping show the relevance of Bluemix to mainframe environment through a series of sessions as well as showing System z as the new cloud disruptor, and there are numerous sessions by other clients like Walmart who will be speaking.

    And so it’s a great opportunity for me to, first to hear stories from our clients as well as to provide some additional sessions for our clients and show what we’re doing, and it will be my first opportunity to have hard copies of this book and do a book signing for any of the client who are there.

    Alan: That’s what I was gonna say—there’ll be plenty of copies of the book there available and signed by yourself.

    Rosalind: Absolutely.

    Alan: Great. Okay, we’re gonna—I think we’re gonna call it a wrap here, Rosalind, and thank you so much for your time. I know you’re busy and I appreciate it. Rosalind Radcliffe, author of Mobile to Mainframe DevOps for Dummies, available now for download or if you’re attending SHARE in Orlando next week, you can get an autographed copy. Rosalind, thank you so much for your gracious time and spending some time with us today. We hope to—you know, best of luck with the great book, highly recommended, and we hope to have you back here soon.

    Rosalind: Thank you for having me, and I’m happy to come back and talk to your audience whenever is appropriate.

    Alan: Okay. Rosalind Radcliffe, IBM, and author of Mobile to Mainframe DevOps for Dummies. This is Alan Shimel for devopsy.kinsta.cloud, and thank you for listening into this DevOps Chat, and join us again soon for another one. Have a great day.

    That’s a wrap on this DevOps Chat. If you would like to be interviewed for a DevOps Chat please contact me at editor@devops.com

  • Part 2: Meeting relentless mobile app demand

    Part 2: Meeting relentless mobile app demand

    As we discussed in  Meeting the Relentless Mobile App Demand of the Enterprise, the enterprise thirst for mobile apps will far outstretch what enterprise internal development teams will be in a position to produce.

    Developers will need every edge provided to them in order to help their enterprise success. And there’s no doubt that IT teams need to be agile and move as quickly as possible and this is as true with mobile development than anywhere. By not being able to meet the increasing demand for enterprise mobile apps, enterprises can’t be as effective and productive as they need to be. That creates substantial business opportunity costs.

    Here are some ways I think enterprises can improve the mobile app development efforts, in addition to what Gartner suggested, detailed in our part 1:

    Adopt agility. Enterprise IT is changing rapidly. The tight collaboration with development and operations teams, drive for agility, continuous development and other approaches that are increasingly mainstream are pushing applications out into production, and updating existing ones, more quickly than ever was before possible. Not only do successful DevOps organizations have short app backlogs, they are more innovative. Our special guest contributor Matt Selheimer wrote am insightful series that culminated with DevOps with purpose: ACT-ing with greater agility that details how to be more agile through DevOps practices.

    The more agile your organization, the more swiftly they can re-adjust and move always be producing the apps that matter and those that will drive the greatest business impact.

    Leverage APIs. Instead of building apps from scratch and creating more data silos, take a page from Gartner’s advice on mode 1 which is building infrastructure and APIs. Most existing large enterprises have enormous data and application and database silos. One effective way, when possible, to unleash that data and reduce silos is through APIs. APIs are the most straightforward way to build the capabilities the business needs through    extending the utility of existing applications.

    Leverage the cloud to the hilt. Whenever possible, it’s time to go cloud first. It’s time to gate legacy on-premises systems and maintain them until they can be displaced. This will include public, private, and hybrid cloud architectures – but the more rapidly legacy on-premises systems can be retired the more agile IT can be.

    Our post, Three tips for maximizing efficiency in the age of the hybrid cloud environment, provides insight into how to manage hybrid cloud environments.

    Choose cloud and development platforms carefully. There are a number of other critical platform questions, too: Can the data be provided wherever the user needs it? Does it help alleviate security, privacy, and regulatory compliance demands? And can the platform help with role-based identity management and provide for auditable access control?  All of these things being provided as utility help expedite application development and clear your app backlog.

    The more people in your organization who can develop the better. This could come in the form of training non-developers to build some of the app capabilities they need in cloud platforms and with very high level coding tools. It’s easier now than ever before for anyone to create business process workflows with hardly any code.

    Be MVP lean. The Minimum Viable Product (MVP) is a viable way to identify mobile apps that are in need and will likely provide the most immediate value. Simply defined, the MVP consists of what is only necessary to get the task done and little more. If the app is successful, it can be improved upon and iterated based on user feedback and business need.

    One way DevOps helps to achieve this is through splicing development time so many apps can be worked on incrementally, and the MVP concept is ideal for this type of workflow. It makes it easy to re-prioritize apps and new incremental work on existing ones based on pressing business priorities.

    I’m sure there are other ways to help make mobile app development efforts both effective and strategic to the enterprise rather than fire-fighting app demand. If you have any ideas, we’d like to hear them in the comments below. What strategies, tools, techniques are your organization using to increase mobile app development efficiency?

  • Meeting the Relentless Mobile App Demand of the Enterprise

    Meeting the Relentless Mobile App Demand of the Enterprise

    Talk to any CIO today and one of the most pressing challenges they face is building mobile apps that enterprises want to use as fast as they need them. Most enterprises today have huge mobile app backlogs with no sign of it getting any better.

    According to Gartner, the demand for enterprise mobile apps will be a $40 billion market by next year. And, according to its latest enterprise application trend findings, by the time 2017 comes to an end, market demand for mobile app dev services will grow five times faster, or more, than internal IT organizations’ ability to meet that demand. Gartner forecasts mobile phone sales will reach 2.1 billion units by 2019.

    “Organizations increasingly find it difficult to be proactive against competitive pressures, which is resulting in their mobile apps becoming tactical, rather than strategic,” said Gartner analyst Adrian Leow. “We’re seeing demand for mobile apps outstrip available development capacity, making quick creation of apps even more challenging. Mobile strategists must use tools and techniques that match the increase in mobile app needs within their organizations,” Leow said.

    Interestingly, according to Gartner, employees today use about three different devices daily. Gartner expects that to hit five or six soon. With many firms embracing BYOD, mobile development teams will be pressured to build more apps under more pressure for more form factors than ever before. And they are already pressured. Consider this: A 2014 Gartner survey on mobile app development found that the majority of organizations have developed and released fewer than 10 apps, with a significant number of respondents not having released any mobile apps.

    In its statement, Gartner detailed four practices it feels are necessary to meet mobile enterprise mobile app demand. They’re a good start, but not enough. I share Gartner’s practices in the next paragraph. The practices I also think are necessary to meet enterprise mobile app demand will be included in a follow-up post next week:

     

    1) Prioritize app development

    Mobile development teams are overstretched and have difficulty effectively delivering the growing number of mobile apps in their queues. The result is apps being built on a first-come, first-served basis, with the line of business making the most noise having its needs met first. This lack of value-driven prioritization leads to inefficient use of IT resources and a degradation in the quality of apps delivered. According to Gartner analysts, mobile development teams need to formulate a process of mobile app prioritization that involves understanding the needs of business stakeholders. This will be a key factor in defining common criteria for evaluating mobile app projects.

    2) Adopt a bimodal IT approach

    Integration is often the largest part of the effort of delivering an enterprise mobile app, with many app development teams underestimating the time and resources required for integration during the planning stage of the traditional waterfall methodology they are following. Gartner believes organizations need to replace this traditional IT development approach with a bimodal strategic approach that supports innovation and agility to deliver apps more efficiently and quickly. Bimodal approaches consist of two models: Mode 1 drives the creation of stable infrastructure and APIs to allow apps to retrieve and deliver data to back-end systems without impacting those enterprise applications, while Mode 2 uses high-productivity, agile approaches to quickly deliver front-end app features required by the business.

    3) Use rapid mobile app development (RMAD) tools

    Using development tools that can produce apps more rapidly is crucial for enterprises to help bridge the gap between mobile app demand and supply. Significant innovation is driving this market and replacing traditional coding approaches, such as native development tools, with more effective RMAD tools. There are many approaches to RMAD, including drag-and-drop codeless tools, code generation and orchestration, model-driven development, virtualization, forms construction, and others. These approaches are allowing those with no programming skills or coding ability, such as people in business roles, to rapidly assemble mobile app prototypes and continuously iterate on these designs.

    4) Adopt a mixed-sourcing approach

    Organizations want to have full control over their mobile app development initiatives, however, maintaining a pure in-house development environment is difficult to achieve given mobile is a relatively new competency to many developers. It entails many complexities and specific activities, such as UX design and psychology or cellular coverage testing, which may be more efficiently handled by an outsourced third party experienced in mobile app development. Gartner believes organizations will improve their in-house mobile development skills over time, but currently only 26 percent of organizations are adopting an in-house-only development approach, while 55 percent are successfully delivering apps using mixed sourcing.

  • The Wonder Pill for Mobile Application Success

    The Wonder Pill for Mobile Application Success

    Dr. James Brown stunned the British Science Festival by announcing a wonder pill that could reduce your weight, lower the risk of high blood pressure, cancer, diabetes, depression, and anxiety. With everyone in attendance eagerly awaiting what it was, he plainly exclaimed that the “wonder pill” was daily exercise.

    The most effective solution was the simple one. The same applies towards developing a successful mobile application.

    There is a sure fire way to generate greater sales, leap frog the majority of your competition, promote wider brand recognition, and win loyal customers. The wonder pill: make sure your mobile application works.

    “The majority of mobile applications get a one star rating from users due to poor quality. Either the apps don’t work properly or they perform too slowly. The best way to guarantee the financial success of a mobile application is to simply test it properly so the user has an ideal experience.” says Tal Barmeir, CEO of Experitest. If a mobile application has a function that isn’t working, 80% users will simply delete it. In some cases they will tell their social media followers about how lousy the company is. They won’t pan the app mind you – they will put down your entire company. Performance is no different. A slow performing application, even if it works, might as well be broken.

    If a daily walk is the simple way to quality health, mobile application testing is the simple way to a quality app. If you can guarantee that your application works properly, your mobile application just leapfrogged the majority of its competition that cannot make that claim.

    Is Mobile Testing as Simple as a Walk in the Park?

    To guarantee top quality of your app you have to test it over all types of devices, and for each device you have to test over several mobile operating systems. For each permutation of device and operating system you need to make sure your application works fast. But be warned! Just because it works fast over a cutting edge local network in Singapore doesn’t mean it will perform as well in rural Indonesia.

    Add in smartwatches, other wearables, and apps managing the internet of things and the matrix of test scenarios you need to cover can seem endless.

    The best testing tools make it look easy. You can set up an on premise mobile device lab in your company, and using the cloud attach as many devices as you want to it. Each device can have a different operating system, creating for yourself a large a matrix of devices and operating systems, expanding your test area to meet your needs. Your quality assurance testers can access these devices by remote using automation testing tools from wherever they are in the company. A manager can decide to assign devices to different testing teams working in different time zones to create a 24 hour nonstop testing operation. By including a Network Virtualization tool, testers can simulate any local network condition on earth. They can verify that their application works as smoothly in Nairobi as well as it does in New York City. The best testing tools also constantly update to enable you to test for new technologies like wearables and the IoT.

    That’s why mobile testing is the wonder pill of mobile application success. It makes your mobile application works. It makes sure your mobile application performs fast. It makes sure your customers and prospects know that your mobile app is the best there is – and they tell their friends about it.

    About the Author/David Fink
    david finkDavid Fink is a product evangelist for Experitest, a leading provider of mobile test automation, manual testing and monitoring tools for mobile applications. David worked on Wall Street during the internet boom of the 1990s and 2000s. Watching the same transformation taking place in mobile, he writes about what we can learn this time around to make this new phase in digital growth usher in smoother to benefit everyone involved. Reach him on Linkedin