devopsy.kinsta.cloud

Tag: apps

Meet the Citizen Developer

Much has been written on the rise of citizen developers, but little about who they are and why they choose to do what they do

The enterprise is always thirsty for new applications. More than ever, this thirst seems unquenchable. Consider a recent market analysis from Global Market Insights, which expects the enterprise application market to grow at a rate of 7.6 percent annually from 2016 through 2024. That’s a clip swift enough to more than double its 2015 $150 billion market size by 2024.

The demand for enterprise applications—and especially for mobile apps—is so high that most enterprise IT departments can’t meet it and often have backlogs of months to more than a year.

We’ve written extensively about how the citizen developer is now stepping up to fill this gap. Citizen developers are helping enterprises to not only close the application demand gap but also innovate more rapidly. However, we haven’t seen much regarding the nature of these citizen developers—who they are and what makes them decide to tackle app development independent of IT.

Recently, Apple subsidiary FileMaker Inc. surveyed hundreds of citizen developers within organizations ranging from five employees to more than 1,000 employees. Those surveyed either created or were involved in the creation of custom apps, didn’t classify themselves as IT professionals and were not full-time custom app developers.

As we’ve written before, we consider the rise of the citizen developer to be an extension of the consumerization of the IT trend, which began with endpoint devices, evolved to include many cloud services and now encompasses citizen development. Just as users began choosing which tablets and smartphones they would use for work, many staff members now are choosing, independently, to shun old-fashioned spreadsheets and endpoint databases for higher-level, cloud-based platforms that make it possible to build applications with little to no coding.

Why do citizen developers choose to develop work apps on their own? According to the FileMaker survey, it’s because a sizable majority—83 percent—wanted to create a better way to work, while 63 percent wanted to be more productive and 42 percent wanted to help others in their organization. Only 12 percent of citizen developers had been asked by their boss to start building apps. Currently, the citizen developer movement is self-directed and self-motivated—41 percent started developing business apps to improve their skill sets.

So who are these citizen developers? Not surprisingly, the majority are savvy computer users with no formal background in computer science or software engineering, and 34 percent play a management or supervisory role in their organization. When respondents were asked what three words colleagues would choose to describe them, about half chose “problem solver.” Other descriptors such as “creative,” “hard-working,” “organized” and “leader” also ranked high.

The citizen developers also reported that citizen development had a significantly positive impact on their career. Nearly half, at 48 percent, cited increased satisfaction at work, while 42 percent found that the practice increased their confidence, 29 percent received more recognition within the organization and had more time to work on efforts they enjoyed, and 26 percent felt increased motivation at work.

Finally, because citizen developers can spot a business need and fill it quickly with an app, they are helping to fill the application demand gap in many enterprises. Eighty-two percent of citizen developers said they witnessed a reduction in inefficient tasks, 71 percent reported an increase in team productivity, and 60 percent said their apps helped to reduce data entry.

They’re building these apps quickly, too—often building their first app in less than three months, according to 71 percent of respondents. Only 12 percent reported it taking three to six months to do so. That type of accelerated app delivery—when the idea is conceived, designed, and delivered by the users who needs the functionality—will not only help to clear app backlogs but also could become a cauldron of internal innovation.

— George V. Hulme

February 3, 2017
How to Avoid Trouble when Deploying Apps to Multiple Clouds
Deployment is where Dev meets Ops. The glue that binds the two is orchestration, which places operations guidelines in the application itself. Here’s how to avoid trouble when deploying your apps to multiple clouds.

Things move faster when your infrastructure is the cloud. Applications go from concept to production in hours rather than weeks or months. Everything happens at the same time: development, testing, deployment, updates. Your tools have to be as quick and nimble as your virtual environments.On the open-source side of orchestration, two scripting tools dominate–Chef and Puppet. As Tom Nolle explained in a July 2016 article on TechTarget, Chef is considered the more “programmer-friendly” of two, while Puppet traces its roots back to the operations side. In practice, however, the imperative or prescriptive Chef model and the declarative Puppet model are “growing closer together,” according to Nolle.

Chef and Puppet: Two Paths to the Same Destination

With Chef, you create “recipes” and “cookbooks” in a programmatic manner; each deployment step is described separately, and the independent recipes are combined into a repeatable app deployment process. By contrast, Puppet has you build a model that describes, or “declares,” what the end state will look like. Puppet models are intended to simplify these deployment descriptions. The Puppet approach is a natural complement to application lifecycle management (ALM) because it accommodates a complete ALM function.Other orchestration tools that take a purely declarative approach are CFEngine and Juju, while Ansible and SaltStack support both declarative and imperative models. The Organization for the Advancement of Structured Information Standards has released the Topology and Orchestration Specification for Cloud Applications (TOSCA), a declarative-based model intended to support both the definition of end-state application deployment and specific modeling of virtual resources and pools.

DevOps as an ‘Easy Button’ for Cloud App Deployment

Today, the components of any application may reside in-house, in a public cloud or anywhere in between. Microservices, virtualization and similar innovations have turned the concept of “infrastructure” on its head. Now the infrastructure adapts to the needs of the applications and services running on it rather than the software adapting to the hardware it runs on. DZone’s Mark Jackson wrote in an Aug. 1 article that IT organizations are evolving from builders and managers of infrastructure to “security-driven cloud service brokers.”

The ultimate goal is to adopt a new approach: a hybrid-cloud stack model based on a programmable, policy-driven infrastructure. In addition to the stack’s infrastructure, management layers are hybrid cloud orchestration and cloud-native stacks that combine to support nearly any type of data-driven app, whether mobile, IoT, hyperscale or vertical use cases.

In a next-generation data center reference architecture, a hybrid-cloud stack accommodates deployment of apps whose components may exist in-house or in public clouds at any given time.

Take the Sting out of Deploying to Multiple Clouds

Organizations that rely on one single cloud service are the exception rather than the rule in today’s IT operations. Flexibility is the name of the game as companies deploy to public, private and hybrid clouds using a range of services: OpenStack, AWS, Google Cloud Platform, HPE and Microsoft Azure, among others. Cloud Technology Partners’ David Linthicum wrote in a March 28 article that deploying to multiple clouds presents three challenges:

• Taking advantage of each service’s native capabilities using generic, relatively new DevOps tools and processes;

• Ensuring your DevOps tools keep pace with the rapid changes being made to the platforms; and

• Maintaining security and governance when each service’s rules for these vital operations are platform-specific.When deploying to multiple clouds, that same code set—usually teamed with data—has to be marked for the target platform at the point of staging. As the app runs through the platform-specific testing, it is checked by the tool or process to verify it will work with the platform’s native features. While this feature-checking can be automated to a degree, it often entails manual rechecks as potential problems are identified and corrected.

Deploying apps to multiple clouds requires platform-specific testing that may not be possible to automate completely.

Once the platform-specific testing is completed, the actual deployment to production on each platform can be automated by placing it on a machine instance in a public or private cloud, and then spinning up the “continuous operations” process. The five components of the process are monitoring, management, resource governance, service governance/service catalog and security:
- Monitoring the application during execution reports any stability or performance glitches when preset thresholds for various subsystems are exceeded.
- Management acts in response to alerts of potential problems by interpreting the monitoring data, usually via a cloud management platform for resource management, as well as primary application and subsystem components.
- Resource governance abstracts the performance data received from individual cloud services through a single console, or dashboard, linked to all the target platforms. User policies can be set once and applied to the various clouds. This is the approach taken by the Happy Apps performance and uptime monitoring service, which provides status and real-time visibility across all your apps and business services.
- Service governance lets you create policies for the use of APIs and services that serve as common services for all the clouds you use, allowing apps to leverage the service on whichever cloud they’re deployed to. A service catalog is used to track infrastructure-level and application-level services in all your clouds as well as on premises.
- Security attempts to minimize complexity in a multicloud model by reducing the number of security services involved, which usually include user authentication, access management and breach detection.
The nature of individual cloud services ensures that deploying to multiple clouds will remain complicated into the future regardless of your preferred set of deployment tools. One way to minimize the complexity is to plan your DevOps strategy from the start with a multicloud environment in mind. There will be times when getting an application to pass data seamlessly across many distinct cloud platforms will require a good deal of manual coding.Adopting a service orientation can mitigate the costs associated with deploying to multiple clouds by sharing services among apps. This way, a single application could run hundreds of remote services from any number of clouds. The service and resource tracking may be daunting at first, but microservice apps prove their business value by making developers more productive and opening doors to new sources of revenue.
September 12, 2016
DevOps and Continuous Delivery: Not the Same

DevOps and continuous delivery are the same thing, right? Far from it. We peer through the fog to understand the difference between the two related but distinct methodologies.

We live in an era of apps. More and more of our personal, social and work life is governed by apps—communicating with one another through social apps, booking cinema tickets through your mobile device or scheduling a business trip through the airline app. This digitization of services has arrived. Organizations that understand this sea change have a unique opportunity to jump ahead of their competitors, acquire customers more quickly and grow revenues.

The battleground for this service development is DevOps. It’s not a product, but rather a methodology for helping organizations build teams and build software. DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other IT professionals while automating the process of software delivery and infrastructure changes. It creates a culture and environment where building, testing and releasing software can happen rapidly, frequently and more reliably.

Organizations are marching with their feet. According to a recent study, market demand for DevOps skills is growing, and DevOps engineers are among the highest paid IT practitioners today. And it looks set to stay that way. Research in the U.K. shows that 30 percent of 300 organizations surveyed in the run up to the 2015 DevOps Summit had either started to implement a DevOps strategy or had already merged Dev and Ops, with another 13 percent planning to go down this route.

Two Related Children: DevOps and Continuous Delivery

So now we arrive at continuous delivery. If DevOps is about accelerating the delivery of new, high-quality services, surely continuous delivery is the same thing, isn’t it? In other words, ensuring a steady stream of new services? You might look at it as a manufacturing production line: DevOps is the machine that builds the service, while continuous delivery is the conveyer belt that rolls the services off the production line—one big unified service development cycle.

That’s not the case. Although the distinction between DevOps and continuous delivery can be a little grey and cause confusion, there is in reality clear water between the two. Continuous delivery has become an essential ingredient for teams doing iterative and incremental software delivery. It is an approach whereby teams ensure that every change to the system can be released, and that any version can be released at the push of a button. Think of it this way: Continuous delivery aims to make releases dull and reliable, so organizations can deliver frequently, at less risk, and get feedback faster from the end users until deployment becomes an integral part of the business process and competitiveness of the enterprise.

Gartner summed up the distinction between DevOps and continuous delivery very neatly with a report that stated, “DevOps is not a market, but a tool-centric philosophy that supports a Continuous Delivery value chain.” The analyst argues that bimodal and digital business strategies stimulate demand for improved speed and effectiveness of software delivery.

Continuous delivery and DevOps do share common traits, though. Both methodologies are aimed at agile and lean thinking: each delivers small and quick changes; each relies on tight business an IT collaboration; and each share the common goal of faster time to market for new services.

However, the goal of DevOps is merge dev and ops roles together—and the processes they manage—to achieve business goals. It’s all about a common, shared culture and enhanced collaboration. About clearly defined business processes.

Automation has an essential role to play in both DevOps and continuous delivery. Automating DevOps helps your organization manage and secure continuous delivery to the business and IT users. The result is a faster, low-risk migration to a new world of composite applications, faster business innovation and better support for rapidly changing business process needs.

April 8, 2016
Mobile Testing’s Role in Staying Alive

Have you ever forgotten to take your pills? You’re not the only one. According to the Centers for Disease Control and Prevention, half of the people prescribed medication eventually stop following their doctors orders.

It’s a dangerous game of Russian roulette. Most of us simply forget. For the elderly, who take more medications with different sets of instructions, it becomes easy to get confused. In cases where their cognitive abilities are diminished due to illness, they can forget on a regular basis. The consequences can be critical.

Almost half of all failed treatments for any illness were a result of failing to adhere to the treatment prescribed. It is estimated that 125,000 Americans die each year simply because they did not take their recommended dose on time.

Mobile technology is changing that.

The newest “thing” to be connected to the web are pillboxes. Smart pillboxes can track if you take your pills, when you took them and the pills you need to take, and even alert you when the box is empty and it’s time to refill your prescription.

If you fail to take your meds, the box itself will send an alert to a caregiver, physician or family member who can call you. For anyone prone to forgetting, this is a life-saver.

The advantages of such a technology are clear. So are the risks. Handing over a life sustaining chore to computers demands that we guaranteeing the technology is working perfectly, all of the time. If the mobile apps fail on us, the consequences are devastating.

Enter mobile testing.

“Mobile application testing makes sure that every function of a mobile app is working all the time, and in any location. It underwrites all the benefits of mobility,” says Tal Barmeir, CEO of Experitest.

Making Mobile Testing Work

A successful mobile application testing strategy can double the chances your treatment will work. To accomplish this, the following areas must be covered:

Functional Testing: From setting the times, to alerting the user, to notifying the doctor or caretaker if a dosage wasn’t taken, every operation of the application must be working correctly. Not only must it work, it has to work on every different type of mobile operating system, over each type of device and in all versions of both.

Automated testing: As the technology advances, new features will be made available quite often. For every new feature added to the mobile application, the entire app must be retested to make sure nothing has been affected—even areas of the app never touched by the upgrade. That takes time. The only way to perform this amount of mobile testing in a reasonable amount of time is automating the process.

Network Virtualization: A doctor can be vacationing on another continent when he or she is alerted a patient has forgotten to take his or her meds. Or, family members can live on the other side of a country and using mobile service from another carrier. Whatever the situation, it is vital that a mobile application will work as effectively in one local network as it will in any of the world’s other 400 to ensure that messages are communicated in a timely manner.

Mobile technology is poised to extend the life expectancy of everybody using top-of-the-line smart tools communicating with mobile health apps. We will all enjoy healthier and longer lives while paying less in the process. The role of mobile testing makes sure this is a safe progression by giving your apps a clean bill of health.

April 5, 2016
Avaya Delivers the Next Big Thing for Developing Digital Business Communications and Customer Service Smart Apps
Avaya Breeze Provides a Next-Generation Technology Platform With a Framework, Development Environment, and the Industry’s First eCommerce Delivery Mechanism for Embedding Open, Mobile Digital Communication

ORLANDO, FL – Enterprise Connect 2016 – Booth #1707 — More than two-thirds of IT executives plan to increase spending on mobile, customer-facing and cloud migration applications over the next two years as part of digital transformation initiatives. But first, IT executives must overcome a significant skills gap that will affect their ability to carry out such initiatives at customer speed.

It’s a conundrum Avaya has solved with Avaya Breeze™, an entirely new way to develop business communications applications.

At Enterprise Connect, Avaya will showcase Avaya Breeze, the next generation of the Avaya Engagement Development Platform — the technology platform that profoundly simplifies application development while delivering built-in capabilities for enhanced mobile, customer-facing and hybrid/cloud requirements. Avaya will also unveil the Avaya Snapp Store – the first eCommerce app store for business communications.

Components of the Avaya Breeze technology platform include:
- An open framework that brings the necessary attributes for communication in the digital age: embedded, multi-platform, mobile, fast, low risk, and workflow enabled — a key requirement to automate previously manual processes to improve digital experiences.
- A development platform for rapid creation of new workflow-based applications within a matter of hours or days versus months.
- A delivery mechanism — the Avaya Snapp Store — that allows a single integrated experience via browsers and native smart apps for entirely new customer experiences.
- Open connectors/APIs that enable simple, integration with existing business communications services and access to the billions of devices in the Internet of Things.
The Avaya Snapp Store is a focused, ecommerce-enabled marketplace for Avaya Breeze applications — or Snap-ins — from Avaya and 3^rd party developers. Snap-ins — easily consumable, prebuilt connectors, fit-for-purpose apps and/or developer code — enable companies to quickly build workflows, customer journeys and other unique applications. The Avaya Snapp Store makes it easy to find, access and download Snap-ins by simply using a credit card for purchase. Developers can create Snap-ins and be on-boarded in the store within weeks.

Gary Barnett, SVP and GM, Avaya Engagement Solutions, said:

“Now, Avaya delivers on the promise of open, mobile engagement with a platform that allows companies to easily design and embed applications into workflows via a powerful, simplified, software-defined architecture and infrastructure for communications. This game-changing technology is built for digital business where companies need the flexibility, speed and the freedom to easily create unique value for their customers. Avaya Breeze liberates them from the confines of monolithic, vendor-locked platforms.”

Avaya is issuing a challenge to the industry to creatively address the major challenges facing businesses and consumers today by developing new apps on Avaya Breeze to help resolve them. To date, thousands of developers from global enterprises have participated in Avaya Breeze Bootcamps and webinars, and are using their lab systems and Avaya Collaboratory accounts to design, build and test Avaya Breeze applications. This week, five of the growing list of third party developers will showcase their Avaya Snap-ins in the Avaya booth at Enterprise Connect, including:
- eGain’s Knowledge Snap-In sends a contextual SMS link to customers on IVR so they can easily use web self-service, without losing their place in the phone queue.
- WEBTEXT uses its global network of SMS messaging gateways to seamlessly connect Avaya contact centers to their customers and the carriers.
- Moxtra’s mobile-first business messaging and document sharing service Snap-In enables rich, persistent collaboration across teams, providing continuity as customers increasingly move between devices.
- Verbio’s Voice Authentication Snap-In addresses increasing concerns about security and identity theft by authenticating users in a fluid and unobtrusive way.
- Approved Contact’s Snap-In provides a worker with more control over who can contact them and when, acting as a personal gatekeeper.
Those interested in developing to Avaya Breeze and/or creating Snap-Ins can learn more by going to the Developer portal at:http://bit.ly/20ZwM0T. For a list of Avaya Breeze Bootcamps and hackathons being held globally, visit: https://www.avaya-learning.com/lms/#/training/catalog/edp

QUOTES:
“I sat there, and I’m not an engineer, but I was dragging and dropping, building a whole workflow for a Web calling service, saying, ‘When this happens, play this IVR message.’ I recorded the message myself, put that in there … and in about two minutes we had a Web calling service Snap-In.”

Daniel Bergan, Head of Strategy and Transformation, Westpac

“More than half of the companies are using or planning to use APIs to embed communications capabilities into their apps, while another 25% are looking at using them to build custom apps. Platforms like Avaya Breeze offer organizations the ability to deliver enhanced business value and execute on their digital strategies by integrating communications and collaboration into workflows, business processes and existing applications.”
Irwin Lazar, VP and Service Director, Nemertes Research

Tags: Avaya, customer engagement, applications development, contact center, digital transformation

About Avaya
Avaya is a leading provider of solutions that enable customer and team engagement across multiple channels and devices for better customer experience, increased productivity and enhanced financial performance. Its world-class contact center and unified communications technologies and services are available in a wide variety of flexible on-premises and cloud deployment options that seamlessly integrate with non-Avaya applications. The Avaya Engagement Environment enables third parties to create and customize business applications for competitive advantage. The Avaya fabric-based networking solutions help simplify and accelerate the deployment of business critical applications and services. For more information please visit www.avaya.com.

Certain statements contained in this press release may be forward-looking statements. These statements may be identified by the use of forward-looking terminology such as “anticipate,” “believe,” “continue,” “could,” “estimate,” “expect,” “intend,” “may,” “might,” “plan,” “potential,” “predict,” “should” or “will” or other similar terminology. We have based these forward-looking statements on our current expectations, assumptions, estimates and projections. While we believe these are reasonable, such forward looking statements involve known and unknown risks and uncertainties, many of which are beyond our control. These and other important factors may cause our actual results to differ materially from any future results expressed or implied by these forward-looking statements. For a list and description of such risks and uncertainties, please refer to Avaya’s filings with the SEC that are available at www.sec.gov. Avaya disclaims any intention or obligation to update or revise any forward-looking statements.

All trademarks identified by ®, TM, or SM are registered marks, trademarks, and service marks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners
March 7, 2016
DevOps Q&A: Datalink’s Dennis Vickers on MobileApps

Companies are custom-building mobile enterprise applications to enhance employee productivity on smartphones. devopsy.kinsta.cloud recently spoke with Dennis Vickers, director of Software Solutions at data center services and solutions provider Datalink about this trend and where DevOps fits in to the process.

devopsy.kinsta.cloud: Why does applying smartphones to business initiatives require so much additional custom-built software?

Vickers: Companies have developed and designed legacy software to group things that need to get done together into applications. With mobile application development the focus is more granular in terms of functionality. It’s not that the applications that we designed for the legacy environment don’t fit on the smaller screen, though they don’t. It’s really that the whole concept of having a group of functionalities in a single application doesn’t really work in a mobile environment. You need to rethink the way that not only your applications work but really the way that you do work. You need to think more in terms of granular work than accumulation of work.

In finance, for example, you might have an application that combines accounts receivable, accounts payable, even expense management. You would have an application that would have all of that functionality in it. For mobile apps, what would make sense is to break out the expense management part of that and make that a mobile app that allows users to be able to use their smartphones to actually capture expenses as they’re incurred, as opposed to having to save a receipt or remember what your expenses were and then go back to an application and fill that in later at the office.

devopsy.kinsta.cloud: How do you apply DevOps development approaches to provide usability on mobile devices for the most needed features and functions of in-house applications?

Vickers: Mobile applications tend to be single functions focused on getting something done. Users are much less tolerant of anomalies in the software, whether that anomaly is a bug, a poor user interface or anything that is undesirable about the application. They’re not nearly as willing to look for workarounds with a mobile app as they are with legacy applications.

You have to have a continuous delivery approach with mobile applications because the time frame between deliveries has to be accelerated. You have to automate that process. We’ve made good use of some of the automation tools, specifically Puppet, around doing continuous delivery. We use tools for source control and QA (quality assurance). Some type of automated delivery process is critical because the turn time for release has to be shortened. There’s just not a willingness for users to wait long periods between releases.

devopsy.kinsta.cloud: Can you discuss the custom-built software project where you developed a custom equipment maintenance app that feeds into the customer’s proprietary maintenance application?

Vickers: We developed that for an aerospace company that had a requirement to provide field service for one of the Department of Defense systems. They had to be able to maintain large pieces of equipment. We had to build an application that enabled them to be at the equipment and do the data collection that they needed at that time. It walked them through the data collection process right then.

Before that, they had a paper process where they would print out instructions, go out and write down the information that they needed to collect, and then go back and enter that into an application. This allowed them to be able to do that closer to the actual event, which cut transcription errors and data collection errors and made the whole process much more efficient. That was an extension of a legacy app that added quite a bit of value.

devopsy.kinsta.cloud: For that Department of Defense project, were there particular development tools or approaches in DevOps for the software?

Vickers: We used an agile methodology where we iteratively released the software and did test and review and then essentially layered the application. We provide a layering process as we build and add features to the application. We delivered to the customer through an automated process using Chef. We use Jenkins to do some release management, but we often revert back to Chef or Puppet.

What we haven’t done a lot of yet, which I think is important and I see growing in the mobile platform, is monitoring. I think that monitoring is an important part of DevOps. I haven’t seen that move into the mobile environment nearly as much as I think it needs to. I think it will happen in the short term. I think there’s some good monitoring tools out there that are coming online or that are maturing and are going to be adopted for mobile app dev.

devopsy.kinsta.cloud: There was another project where you custom-built a jobs app that enables union members to apply for posted jobs without going into the union hall.

Vickers: We developed a mobile app so union members can review jobs that are available and request the job through the app. They can receive job assignments and electronic tickets to go out and do that job. It saves traveling down to the union hall on a regular basis and makes the whole process much more efficient.

The only difference in that project is that we needed to integrate with the back end through an API. The tool we used to help us interface with that API and manage that API integration was Postman. We use it for testing, managing and documenting APIs we build or work with.

February 16, 2016
DevOps, Containers and Faster Time-to-Parity

DevOps discussions often focus on the value of getting innovative applications to market quickly. And it’s true. Getting a cool new application into production quickly can help you differentiate yourself in today’s app-sensitive marketplace.

But, in reality, most development is devoted to “Me Too” applications—and these apps are no less important to the business than the much rarer innovative ones.

In fact, as ironic as it may seem, consistently rapid time-to-parity may be more important to the business than occasionally rapid time-to-innovation.

The Power of “Me Too”
Every marketer and salesperson knows the power of “Me Too.” Yes, in competitive markets, it’s good to have something the other guy doesn’t. But that differentiation can be for naught if the other guy also has something you don’t.

Conversely, you can quickly neutralize any advantages your competitors gain by simply replicating them ASAP.

That’s why ….

–THIS STORY HAS BEEN MOVED TO CONTAINER JOURNAL–

About the Author/Aruna Ravichandran

Aruna Ravichandran is vice president of DevOps Solution Marketing and Management at CA Technologies, responsible for cross-portfolio solution marketing for DevOps across all product lines. Before joining CA Technologies, Aruna held several management positions in product marketing and engineering at Juniper Networks and HP. Aruna earned an MBA and master’s degree in Computer Engineering from Santa Clara University and holds a bachelor of science degree in computer science from Bangalore Institute of Technology. Ravichandran is on twitter @aruna13 and on Linked in

June 1, 2015
Five areas of software development innovation to watch

Software development has undergone a massive transformation in the last two decades. From the first wave of breakthrough do-it-all PC applications such as Lotus 1-2-3 and Microsoft Office, to the launch of the first iPhone and its all-new “app” category, to the recent release of the iWatch and its projected evolution of apps, developers have never been more in demand to support these new technologies.

In May, my company Gemini Solutions will be celebrating our 10-year anniversary, and we’ve been fortunate to have worked first hand on huge advancements. Our close partnerships with some of the most innovative technology companies have given us firsthand insight into areas of significant change, growth and importance for software engineering.

1. Mobile Keeps on Rolling

The biggest area on the horizon for developers is the increasing prominence of mobile. Active in the mobile space since 2007, we have seen the demand for mobile-focused projects explode in recent years, and anticipate it is only going to get more popular. This space has seen incredible change in just a few short years. iOS app development continues to be the most requested, but we’re seeing a lot of growth in Android as well and expect it to continue to gain prominence as more Android devices enter the market. As Microsoft establishes itself as a platform, its apps will not be as in demand as iOS or Android, but I have a feeling that we’ll see growth for them as well.

2. Be Aware of Wearable Apps

Apps are no longer limited to mobile and are branching out to new devices, such as smart watches and bracelets, as they gain in popularity. There’s been a lot of buzz around Apple’s iWatch and the demand for the device is expected to be huge. We’re already receiving requests for the development of wearable apps so companies can keep up with the technology. Many of the inquiries are consumer-focused at the moment, but are beginning to move into the enterprise as well as these devices have the potential to become a one-stop-shop for both everyday and business uses. In addition, we believe that connected app development is also going to increase sharply in prominence. As these new devices link to mobile phones, tablets and computers the demand for interconnectivity is going to be huge.

3. Functional Programming Making a Comeback

We’ve noticed that the functional programming model is starting to see an increased push again. Scala is very popular for functional programming and is gaining traction with developers. We’ve also noticed people using Scala in conjunction with big data installations. JavaScript is immensely popular right now as well and we’re also seeing increasing use of Angular. This space is constantly changing and we expect to see even more infrastructures appear to offer more variety and choice for development.

4. It’s the Real Thing: The Internet of Things

The Internet of Things is the perfect amalgamation of mobile, embedded and cloud. The Internet of Things is bigger than the Internet of Humans. We’re seeing a lot of intelligent connected devices appearing on the market, and this is only going to accelerate as demand increases. A prime example is the popular internet-based security systems, with web-enabled locks, internet-controlled light and heating/cooling accessibility and the ability to view your home at any time via the device of your choice. Companies continue to make large investments in this space, prompted by the growing popularity of connected devices. We’ve been working with the Internet of Things for several years, but it is still a new frontier in many ways and we’re looking forward to being part of the space as it continues to develop.

5. Making a Big Deal About Big Data

In just a few short years, the hype of Big Data has gone from dream to reality. Everyone has their own interpretations of what Big Data actually means, but don’t let that fool you into thinking it’s a flashy trend; it is here to stay. The cloud is emerging as an increasingly popular way to develop and test new analytics apps and for processing big data outside of the enterprise. Data agility will also become even more central as organizations begin regularly using massive amounts of data, as opposed to just capturing and managing it. The umbrella of big data covers many disparate applications. Being able to analyze massive amounts of data to determine user activities, actions and preferences will be priceless to companies, and is why we will continue to see this space explode in popularity.

The software development space has never been constant or stagnant. Huge advancements and innovative new technologies are continuously appearing to change the game and open up new possibilities. We have been honored to be part of this movement for the past decade to help drive these crucial projects forward. If the past 10 years were any indication, the future of software engineering will be bright, unpredictable and unfathomable. I can’t wait to be there for the next chapter.

About the Author/ Theo Nissim

Theo Nissim, CEO, Gemini Solutions – Theo is a seasoned Silicon Valley technology executive with more than 20 years experience. He has led pre-IPO start-ups, built dozens of technical teams, developed technology strategies and driven innovative products and solutions to market. One of Theo’s many strengths and passions is managing large scale, cross-functional development efforts to high profile product releases. Theo has held executive and management positions with large public companies, Sun Microsystems and Wind River Systems, and served as the Engineering Vice President for VC funded start-ups, Digital Fountain and AdKnowledge.

Theo has a Masters Degree in Computer Engineering from the Technion, Israeli Institute of Technology in Haifa Israel. He lives in Palo Alto, California, with his wife and twin boys.

May 13, 2015
Swapping Engines In Flight: Transforming Brownfield Enterprise Applications
As DevOps thinking becomes more mainstream, enterprises will need to incorporate new ways of developing and delivering applications into their standard IT processes. Enterprises that are often complex and constrained by existing legacy infrastructure, organizations and processes must consider how and when to transition brownfield enterprise applications to an agile approach. With production applications on legacy infrastructure, how do you think about “changing the engine on a flying plane”?

DevOps guru and practitioner Rob Berger joined me on a recent devopsy.kinsta.cloud webinar to deep dive on these topics.

What Is Brownfield?

The EPA defines brownfields as “real property, the expansion, redevelopment, or reuse of which may be complicated by the presence or potential presence of a hazardous substance, pollutant, or contaminant.”

It’s humorous to think about our enterprise legacy apps being toxic dump sites and might feel that way at various points in our efforts to transform them, but in our world, brownfield simply refers to an existing application or service that is already in production. It was likely built using previous generation tools, serving mainframe or client server architectures, any time from decade(s) to a few years ago.

While “legacy” conjures images of a sleepy, backwater enterprise, brownfield is actually ubiquitous. Any company with existing computer based services has brownfield transitions to figure out because you can’t just throw away what’s in production today. Even when doing startups, it’s amazing how fast legacy can happen.

So how do you think about continuing to serve customers with an existing brownfield application in production, while transforming it into a modern web-scale application?

A Note On DevOps

Remember that first and foremost, DevOps is a process and journey. Different organizations are going to be at different stages at being DevOps.

Rob referred to Conway’s law, which states that “organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.” The takeaway is, make sure that the organization is compatible with what you’re trying to achieve. It is so critical that you break down silos and improve communications between all parties involved, even more so than the technology.

So, What Apps?

Enterprise applications largely fall into three categories. Many are going to be pre-existing custom applications, the kind that are wrapped around core organizational structure or business functionality. They are both the most challenging applications to transform, as well as the highest reward to figure out. You want to figure out how to offer things like mobile or web apps that leverage the existing app to slowly transform to the new way of doing things.

Related to the pre-existing applications are packaged applications from vendors because they can be as much wrapped up in the way you do business as the custom apps. Some vendors can support the migration, but more often you will have to identify the most critical new business functionality and move that to the new DevOps style.

In some ways, the easiest to deal with are new applications. They are greenfield opportunities to start from fresh with a new DevOps style team, with continuous integration, test driven development, and an organizational structure that reflects that.

Let’s say that you have a monolithic existing application that was written 8-10 years ago using standard open source technology C++ or Java in a waterfall model by a large system integrator. The market demands that the service modernize beyond the incremental changes that occur in the long cycle releases. What are the steps that you would go through to transform this app to the DevOps world?

Step One – Minimum Viable Product

You don’t want to create a complete replacement of your legacy application, and certainly don’t want to disrupt your existing business. But you do want to evolve it so that you can meet the needs of your more modern demands.

At the organization level, identify the most critical thing that you must deliver. What is the highest priority demand and what gives you the most bang for your buck? What is the “minimal viable product” for this new thing you want to do? Figure out the smallest scope to transform that will have the biggest impact. A easy example might be to add a mobile interface to your existing system because it just maps the user interface with the same business logic in the back end.

Step Two – Create The (Right) Team

You need a small team that has a mix of the right people to deliver this minimum viable project. It requires representation across functional groups
- Business group or product manager,
- Key developers,
- IT operations who will automate the creation of the service (not just jockey a server)
Look at your current organization and architecture to identify the people that can adapt to the new way of doing things. Finding the right people who believe in the new way of doing things is critical to building responsive apps, per Conway’s law. Understand the internal politics and how to mitigate interpersonal dynamics. Don’t get bogged down in the past, but you need functioning teams that collaborate well to not disrupt your business.

Step Three – Build REST APIs

Your new application will built as self contained services for manageability and scalability, exposed through REST APIs. Identify what services you need from the legacy system, and create REST API around the legacy system that can expose the services from the legacy system to the new system. You will need people that understand both the legacy and new system to make this work.

One of the biggest variables will be how to most gently and elegantly wrap a REST interface around the legacy app. You want the new system to just talk to REST, and it doesn’t need to know anything about legacy app.

Step Four – Design The New Service

Use modern tools. Microservices should be at foundation of whatever you do. Figure out the components that can be considered independent and have its own lifecycle, tied together by REST or JSON interfaces. By identifying the minimum viable product, you should be working in 2-3 week cycles so that you can see the results fairly quickly.

Why Microservices

Your new apps should be loosely coupled architectures that are called microservices. Microservices tend to use RESTful APIs as the primary way that they communicate.

Think of each microservice as a functional block, like in functional programming where there are specific inputs and outputs, and the side effects should be non existent or very controlled. This allows you to know precisely to know what’s going on inside each box. Interoperation is explicit through REST or streaming interfaces. In both cases you can have schema repository that becomes the definition of how microservices talk with each other.

Automate Everything

Every time a software developer commits code into a Git repository, it should automatically be deployed into a QA or staging environment. Lay that rule down from the beginning. If you’re building individual servers by hand, that’s a good indication that you’re going to have problems. The goal is for everything to be scripted or your infrastructure represented as code, using configuration automation system like Chef and Puppet at the core of how you are deploying services.

You almost want to treat servers like immutable things that you throw away when you want to update it. The only way to do that is to automate, which leads to the application side concept of continuous delivery or continuous integration. Get to policy driven management, where policies are embedded in code.

Remember, You’re Not Replacing Your Legacy

This is a journey and you’re just starting on the evolutionary path for independence.

Keep in mind that you will likely have both the old and new running in parallel for a short time. You’ll want to figure out how to use your legacy system as a back end, with a decoupled front end that can then evolve independently to the back end. And leading to the next point, remember that your team running the new components and the legacy app will have to collaborate closely as you transform the enterprise.

About the Author / Varma Kunaparaju

Varma Kunaparaju is CTO at Vistara and a seasoned technologist with over 20 years of experience leading engineering teams to deliver enterprise software. Reach him on twitter: @varma1
April 17, 2015