Native mobile and DevOps will be a continued focus, and "cloud computing" will become simply "computing"


Last year, I wrote a blog post on what my enterprise technology New Year's resolutions were -- working with customers to help navigate the influx of consumer-focused companies entering the enterprise IT space. The push of consumer companies into the enterprise didn't increase as I expected, but we did help some customers move their digital documents and knowledge bases to some of these consumer company's enterprise offerings.

Moving into 2016, I find myself less focused on resolutions and more interested in what's next for the industry. Here are the trends that I expect to see customers in the software development space more interested in in the coming year:

Continued wave of everything natively mobile: The responsive Web will continue to not be enough. Companies will continue to move their products and offerings to native mobile apps and consumers will demand that their experience move with them through their devices. I started my purchase on my tablet, but completed the transaction on my phone.

Acceleration of DevOps adoption: As I've written about here before, interest in DevOps has exploded this year, and with good reason -- it's an effective software development services method that facilitates communication and collaboration between different parts of an organization. This is a trend that I see not only carrying into 2016, but continuing to grow exponentially. As companies become more integrated and continue to move large amounts of data to the cloud, the necessity for DevOps will only increase.

Greater demand for increased privacy: Online privacy got a lot of attention this year, and not all of it good. It seemed that no one was exempt from damaging data breaches, from major banks to the now-infamous extramarital dating site Ashley Madison. With the influx of more sites and even apps that are responsible for safeguarding personal information (like Venmo mobile banking and ZocDoc) I expect that consumers will be demanding more efficient safeguard and companies will be charged with making those adjustments -- and fast.

Cloud computing will be a thing of the past: This isn't because the cloud is going away, not by a long shot. Rather, "cloud computing" will simply become synonymous with "computing." There are virtually no businesses that are not using the cloud currently in some capacity. But those that aren't will need to get on board quickly, as it has become an essential part of not only working with customers, but also managing internal operations.

Only time will tell what trends will truly take off and what new advancements we'll be reflecting on this time next year, but the one thing that I can guarantee is that when it comes to software technology, things can change quickly.


Scrum is a flexible and collaborative way to manage a software project. It’s a framework that lets you move quickly and pivot easily when needed.

While scrum is favored among many technology leaders, what makes it so attractive for managing projects? Below, technology executives from Forbes Technology Council explain how and why adopting agile methods can help your team TISI +% achieve their goals.

1. A Faster Feedback Cycle

Oftentimes, you build something exactly as per requirements, but it turns out that’s not what business stakeholders wanted. Instead of finding that out six months after the project started, scrum helps you avoid that by providing something tangible to show users by the end of the first sprint. Then you get feedback and continue to iterate until you build something everyone is happy with. – Alexander Kharlamov, Madison Square Garden Company

2. The Change Is Constant

The key benefit of the agile methodology is that it acknowledges the reality of a software development project — namely, that things will change. Adhering to agile-friendly project management frameworks like Scrum keeps changes from disrupting a project and turns them into a positive, both for the project’s outcome and the team. – Jim Walsh, GlobalLogic

3. It Identifies Problems Early

Daily, all-hands scrums keep meetings brief and staff on track. Bigger problems get identified early and taken offline without wasting the time of the entire team down the road. – Chris Kirby, Voices.com

4. Flexible Prioritization

Scrum methodology allows us to be flexible in prioritizing customer-driven features. Within each sprint boundary, we are able to better manage our shippable units of work and make overall progress towards a final product milestone. To get a timely ROI from engineering, their work needs to be shipped and customers need to realize value from those features as early as possible. – Venkat Rangan, Clari Inc.

5. Maintaining a High Potential for Customer Satisfaction

Scrums allow teams to respond to changing plans effectively and measure productivity over time to anticipate future workload. Customers are happy because they have a higher probability of getting what they wanted. Internal teams are happy since they can fix important bugs and push them out the door faster. – Chalmers Brown, Due

6. Seeing the Benefits of Your Labor Sooner

When done correctly, you gain value (and customer learning) iteratively. This allows you to harvest the benefits of your labor sooner, and course correct as needed. – Danny Boice, Trustify

7. Free Commitment and Accountability Measurement

Working in sprints allows you to accurately measure your team’s accountability and level of commitment. This helps you understand your team’s velocity, which allows you to set realistic levels of commitment. Once you’re here, you’re able to more accurately make promises to the business, which leads to success. – Matt Boyle, Shapeways

8. No Need to Waste Time Creating and Adjusting Detailed Project Plans

Scrum acknowledges that the best solutions come from an iterative learning process with frequent releases. In traditional project management, there is a lot of energy spent on managing a project plan as things are learned. Scrum acknowledges that learning is a part of the process and removes the need to make plans that are going to change anyway allowing full focus on the task at hand. – Dmitry Koltunov, ALICE

9. It Gives Your Team Purpose

Most agile methodologies focus on creating a shared sense of ownership and goals for the team. Use this to give your team “purpose” instead of trying to artificially create urgency. Purposeful teams get more done and set a faster pace for themselves. – Erik Gustavson, Bitium

Source:  http://www.forbes.com/

Agile Software Development Services
I honestly cannot believe I actually have to write this but this just in, pretty much entire world is on a mobile device on pretty much the whole time they are awake. In other words, the world of mobile marketing and its ridiculously enormous benefits should come as no surprise to anyone.
I have written countless articles on the topic of mobile marketing going back years. I don’t say to imply I am some sort of soothsayer or anything like that. I merely bring that point up to highlight the fact that mobile marketing is not something someone in the marketing world should just be waking up to.
Ok enough about that.
I’ve put together a high-level list for CMOs or any marketer for that matter to consider when looking at their mobile marketing strategy. 

1. Mobile App or Mobile Website?

Many companies rush forward and create an app just because their competitors have one. But not every company needs an app. Often a mobile-optimized site will meet most requirements. Mobile apps, however, generally allow for more creativity, and better interaction with your targeted users.
According to Janna Badalian, Director of Marketing at MobileSmith, “When it comes to customer engagement, native mobile apps can give your website a run for its money.You can engage various groups of customers and offer them a superior user experience – even without a reliable Internet connection.”

2. How Are Your Customers Using Mobile?

Use analytics to understand how your target audiences are using mobile. Are they transacting or using it to gather information? Are they mostly on Android or iOS; smartphones or tablets? Translating this data to your IT will help them make the right decisions and prioritize development plans. However, sometimes requirements can get “lost in translation.” Marketers usually know best what their customers expect from a mobile app, and they can get their idea to market quicker if empowered with the right app prototyping and development tools.

3. Get to Know ASO

What is ASO? App Store optimization. The App Store can be a great source of new customers or it can be a competitive nightmare where your app never sees the light of day. Getting to understand ASO is a critical part of gaining traction and maintaining traction in the App Store. Sites like apptamin.com offer great information on the subject. 

4. Get to Know Your Competitors

Download your competitor’s apps. Not just you, but everyone on your team should get to know what’s out there and how the competition operates. Not only will you get some ideas, you will find out what they are not doing well which will give you an opportunity to identity ways to beat them. 

5. Check Cost Per Download

This is a fundamental issue that hits the business side of marketing your company with an app. It’s one thing to develop an app, it’s entirely another to motivate customers or potential customers to download the app. 

6. Consider In-App Advertising

CMOs should look at the app landscape and focus on popular apps with frequent usability. Popular apps like Twitter allow in-app advertising or mobile advertising, and that’s one way to quickly distribute your app. 

7. Use Social Media to Acquire Users

You should consider every distribution point that you think is efficient, but certainly use mobile social media platforms. The technology offers an almost immediate access to download your app. Your creative plan to drive consumers to download must be spot on, or your app will fail. 

8. Double-Down on Mobile

The future of marketing is mobile: Mobile is the most personal device we possess, which makes it the best device to market to. In addition, time spent in mobile apps has already surpassed time spent on desktop Web, and for some parts of the world, mobile devices are the first and only computer people possess. 

9. Use Mobile App Marketing Automation

CMOs are already familiar with marketing automation on the Web; however, mobile apps present a lot of unique challenges and opportunities. On the Web, marketing automation is predominantly a B2B market, whereas apps are primarily for consumers. Also, the primary use case for marketing automation on the Web is lead nurturing, whereas with mobile apps it’s about engagement, retention, and lifetime value. Therefore, CMOs responsible for mobile apps should adopt marketing automation solutions specifically designed for mobile. 

10. Take Advantage of Real-Time Location

Location is one of the great opportunities for marketers on mobile. CMOs should experiment with iBeacons and geo-fences, not only to be able to segment users based on where they’ve been in the past, but also to design marketing interactions for users as they enter or leave certain locations. For example, switch the user experience in the app to “in-store mode” once a user passes by the iBeacon at your storefront, or send a survey to hotel guests as they leave the geo-fence of the hotel. 

11. Be Lean!

Mobile holds tremendous promise, but it’s also uncharted territory for a lot of CMOs. We can’t rely on gut feeling of past experience to build a successful mobile app. Instead CMOs should adopt a culture of data-driven decision making and build their app incrementally. That involves relying on A/B testing and analytics for optimizing both the in-app experience and all marketing interactions, such as push notifications. 


Source: http://www.forbes.com/
Google's Android IDE allows developers to sample APIs and features of the Android N Developer Preview

Google is positioning its Android Studio 2.1 IDE, released this week, as a mechanism for building applications for its Android N Developer Preview version, which was launched in March.
Version 2.1 updates wizards, the build system, and emulator. Developers can sample APIs and features like the Jack (Java Android Compiler Kit) compiler, which compiles Java source code into Android dex bytecode, in the Android N preview. "Installing the Android N preview SDK requires Android Studio 2.1," said Reto Meier, Android developer advocate.
The IDE now supports Java 8 language features in Android N, including lambda expressions and method references. It improves Instant Run, although the Jack compiler currently does not support it.
Compilation and build times have been improved as well. "In previous versions of Android Studio, a single line of Java code change will cause all the Java sources in the module to be recompiled," said Jamal Eason, Android product manager. "Now, in Android Studio 2.1, incremental Java compilation is enabled by default to reduce compilation time by compiling only what is needed."
Google is improving build times by using in-process dex, converting class files to dex files within the Gradle daemon process, Eason said. "This avoids the costly processing operation of creating separate dex processes. To use this feature, you will need to increase the amount of memory available to the Gradle daemon to at least 2GB (1 GB is the default). "
Version 2.1 also includes a number of bug fixes and stability improvements, especially for users of the Android N preview SDK, Meier said.
Android Studio is Google's official IDE for building Android mobile applications. It's based on the IntelliJ Idea IDE and features a Gradle-based build system.
Source: 




In the 1990s and early 2000s something happened in the software development world, something that wasn’t good. Software development fell victim to the bean counters and micromanagers of the world and followed a project management script known as the “waterfall method.” The waterfall method was fine for projects that were simple and well-defined, but many many software projects fell out of this realm with either changing requirements, or trying to understand new technology—or sometimes both at the same time.
As a result, many software development projects in the ‘90s were organizational nightmares. Much of the purpose of developing software to begin with (i.e., why are we building this?) was lost as organizations devolved into procedural nightmares and territory fights.
This is the short story of the agile revolution—a term you may have heard of. But you probably didn’t realize was a cultural revolution. 
What was the problem?
The waterfall method of development looks like the following diagram. 
Graphic of the basic waterfall development cycle.
Basic waterfall development cycle. 
Requirements are written, then the software is “designed,” then it’s coded, then tested, and then it goes into a maintenance cycle.
As software grew in scope, different teams evolved to focus on different stages of this cycle. The people who designed the software were often different from the people who coded the software. As were the people who tested the software. As were the people who spoke with the customer and wrote the requirements. And where does the customer fit in?
What tended to happen was that the customer often didn’t know all the requirements at the beginning of the project, so projects could get stuck in this phase for long periods of time, and/or as requirements were passed to designers and then to programmers, they lost something in translation or new things came up.
What this process often looked like was a long development cycle with very little to show for it at the end. If something wasn’t going to work, you didn’t know about it until a year later and $2 million down the toilet. We used to have a standard joke at one of the places I worked at: If you went to IT, regardless of what you wanted, they would tell you it was going to take six months and cost $1 million. No joke—I received this quote for a website I built myself over a weekend as a mockup.
Graphed out, it looks like the following: 
Graph of value delivered over time for the waterfall method of development.
Value delivered over time in “waterfall” development—everything is delivered at the end and the risk of failure grows with time. 
You don’t see any results (or value) until the end of the process and it takes a long time. The risk of failure is also highest at the end of the process. Basically, this means that the chance nothing works and you’ve blown through a lot of money with nothing in return is very high.
What was the problem?
A daily spring meeting in Denmark.
A daily agile “sprint” meeting in Denmark. Imagine, designers and programmers and customer account managers all talking to each other! 
It’s tempting to think that the problem was the process—and there’s a bit of truth here. The real problem though was the culture of micromanagement that developed around trying to create organizations to “manage” the waterfall process. The thinking, at the time, was that if we could just nail down this process correctly, everything would be great and work like a machine.
The problem was the beliefs people held.
They valued processes and tools. They viewed complex development in the same way as a manufacturing line. And they forgot about the customer and what the customer was looking for.
The agile manifesto
How did things change?
In 2001, a group of software developers met at a retreat in Utah to talk about lightweight development methods. At this conference they wrote a manifesto—yes, a manifesto—about the cultural change that needed to take place.
The manifesto is simple and looks like this: 
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
There are 12 associated principles of agile software development as well, but the above is their vision statement.
Literally, they stated four key beliefs that ran counter to much of the thinking of the day (and even some thinking that still persists today). They valued individuals and interactions over process and tools, working software over endless documentation, collaborating with customers, and responding to change over some hardened set of never-changing requirements.
02_split_pyramid_150.png
The results pyramid of of Roger Connors and Tom Smith as described in their book “Change the Culture, Change the Game.”  
They realized that they needed to change ingrained beliefs and culture in order to see a difference in results. Though many people still think agile is about changing process, it’s really about changing the culture to one that understands complex development and how it works. 
The easiest way to think about this is that what we tend to see day-to-day is shaped by what we don’t see—our experiences and beliefs. If you simply change a process, you often don’t really change core beliefs that can lead to terrible results. For example, if people on the team and especially leadership positions value processes and tools over people working together, no process or tool is likely to have much of an impact.
One of the results of agile change is that development changes to a more incremental plan: Let’s see if we can get the customer something in a couple weeks to show, and then let’s build on this value. Subsequently, as a result of thinking about how to deliver value incrementally, risk decreases over time (and you tend to know quickly if something is going to fail). 
Incremental development and risk.
Incremental “agile” development — value is delivered in small increments and the risk of failure decreases with time. If you’re going to fail, you find out quickly at something small. 
Wrap
As we think and talk about revolution, think about the agile manifesto. Think about agile groups like Occupy Wall Street that worked toward cultural change. Ignore the cries to “have an ask”—these are attempts to shift the conversation to the top of the pyramid rather than change bad ideas. 
And think about what we want to value. Do we value people more than tools or processes, or even profit? Do we value living in silos and fighting with each other over every crumb, or do we all gain something from working with each other? Do we value individual power or do we value all of our voices? Do we value hierarchical rule or do we value democracy?
Again, remember this doesn’t mean any one thing is worthless. It’s just to say we value one more than the other.  
The agile manifesto has led to a revolution in the software industry. It also gives hope for reviving democracy and restoring some of the values I fear we’re losing. 
Source: http://www.dailykos.com/

Search This Blog

About Prima Business Solution

Popular Posts