Forrester cloud computing expert James Staten recently published 10 Cloud Predictions For 2013 with contributions from nine other analysts, including myself. The prediction that is near and dear to my heart is #10: "Developers will awaken to: development isn't all that different in the cloud," That's right, it ain't different. Not much anyway. Sure. It can be single-click-easy to provision infrastructure, spin up an application platform stack, and deploy your code. Cloud is great for developers. And Forrester's cloud developer survey shows that the majority of programming languages, frameworks, and development methodologies used for enterprise application development are also used in the cloud.
Forget Programming Language Charlatans
Forget the vendors and programming language charlatans that want you to think the cloud development is different. You already have the skills and design sensibility to make it work. In some cases, you may have to learn some new APIs just like you have had to for years. As James aptly points out in the post: "What's different isn't the coding but the services orientation and the need to configure the application to provide its own availability and performance. And, frankly this isn't all that new either. Developers had to worry about these aspects with websites since 2000." The best cloud vendors make your life easier, not different.
More and more data is stored online by both consumers and businesses. The convenience of using services such as Dropbox, Box, Google Drive, Microsoft Live Skydrive, and SugarSync is indisputable. But, is it safe? All of the services certainly require a user password to access folders, and some of the services even encrypt the stored files. Dropbox reassures customers, "Other Dropbox users can't see your private files in Dropbox unless you deliberately invite them or put them in your Public folder."
The security measures employed by these file-synching and sharing services are all well and good, but they can be instantly, innocently neutered by a distracted programmer. Goodbye privacy. All your personal files, customer lists, business plans, and top-secret product designs become available for all the world to see. How can this happen even though these services are sophisticated authetication and encryption technologies? The answer: a careless bug introduced in the code.
Below is some Java code I wrote for a fictitious file-sharing service called CloudCabinet to demonstrate how this can happen. Imagine a distracted programmer texting her girlfriend on her iPhone while cutting and pasting Java code. Even non-Java programmers should be able to find the error in the code below.
Think you developed a secure mobile app? Think again. Many mobile app developers have a naive notion of app security that leads them into believing their apps are secure when they are not. Some developers authenticate users and encrypt passwords and think that they’re all set, but there could still be security holes so wide you could sail a ship through them. The results of releasing an insecure app can include financial loss, reputation tarnish, lawsuits, and Twitter shame.
When designing your mobile apps and mobile backend services, be sure to consider the six security properties of confidentiality, integrity, availability, authentication, authorization, and nonrepudiation (see Figure below). Simply considering how each security property applies to your app won't make it more secure. You will need to perform threat modeling on your design and find solutions to secure your app based on your specific technology and use cases. Don't forget that the mobile backend services must be secure too.
When getting introduced to a new subject or new people, we sometimes play a game called "two truths and a lie." The basics of the game are simple: Anyone introducing a subject - or themselves - states two truths and one lie. The audience then has to identify what the lie is.
Below, you will find three bullets related to our future of software development research. Two are truths as identified by our research, one is a lie:
Software's fueling today's disruption, becoming embedded in everything to make technology useful, usable, and desirable.
Software development expertise will increasingly be centered on Java, .NET, and proprietary development and application platforms.
The U.S. Bureau of Labor Statistics projects software-development-related roles and jobs to increase at double the national average through 2020.
Security threats develop and evolve with startling rapidity, with the attackers always seeking to stay one step ahead of the S&R professional. The agility of our aggressors is understandable; they do not have the same service-focused restrictions that most organizations have, and they seek to find and exploit individual weaknesses in the vast sea of interconnecting technology that is our computing infrastructure.
If we are to stand a chance of breaking even in this game, we have to learn our lessons and ensure that we don’t repeat the same mistakes over and over. Unfortunately, it is alarmingly common to see well known vulnerabilities and weakness being baked right in to new applications and systems – just as if the past 5 years had never happened!
A recent report released by Alex Hopkins of Context Information Security shines a light on the vulnerabilities they discovered while testing almost 600 pre-release web applications during 2011. The headlines for me were:
On average, the number of issues discovered per application is on the rise.
Two-thirds of web applications were affected by cross site scripting (XSS).
Nearly one in five web applications were vulnerable to SQL injection.
It makes depressing reading, but I’m interested in why this situation is occurring:
Are S&R professionals simply not educating and guiding application developers?
Are application developers ignoring the training and education? Are we teaching them the wrong things or do we struggle to explain the threats from XSS and SQL injection?
Are our internal testing regimes failing, allowing flawed code to reach release candidate stage?
Think of a medieval fortress: It was originally used for a small army, it has walls nine meters thick, and it’s surrounded by buildings hundreds of years old. Upon entering, you are confronted with the concept of eternity.
This fortress is located in the smallest state on earth — though it is also perhaps the best-known state in the world. The business housed within the fortress is what many might classify as a SME but with with complexity of a large enterprise, holy but busy, centralized but truly global — its work spans hundreds of countries with hundreds of currencies and hundreds of languages — and it serves very special and demanding clients.
Have a clue yet of where we are?
Zoom on Italy, then zoom on Rome, then zoom on Vatican City, and you can’t miss the round tower (Torrione Sisto V) where the Vatican Bank, or Istituto per le Opere di Religione (IOR ), is located. You won’t be allowed in if you are not a client, an employee, or part of a religious congregation. Change comes hard to institutions this steeped in tradition. To give you a clue, IOR’s previous managing director spent his entire career at IOR — 60 years — and retired at the age of 80. We all know it’s the soft and cultural aspects of transformation that are the hardest part for any organization.
Nevertheless, IOR has been going through a major change since 2008, working to replace its legacy IT system with a modern BT one. The new BT system brings more flexibility for the business, richer business functionality, and greater integration and development capabilities. Enabling fast change is the key driver for IOR’s IT transformation program from IT into BT.
Never has a new trend annoyed me as much as Agile. Right from the get-go, the Agile Manifesto revealed the weaknesses and immaturity of the founding principles. The two most disturbing: “Working software is the primary measure of progress” and “Business people and developers must work together daily throughout the project.” These are
Two weeks have passed since our successful AD&D and BP Forums in Boston. I’m still struck by conversations we held there and continue to hold now with many of you on how your teams can help deliver to your firm’s ever-important customer experience outcomes. Following one tip can help you either get ahead of this issue or catch up to the expectations of your stakeholders…act more like an interactive agency!
Note I didn’t say “transform” into an interactive agency. No, at the end of the day you have responsibilities to your organization the agencies your business peers use often don’t – you have to manage, operate, and maintain what’s been delivered. What I did say was “act” like one, and in doing so you’ll need to:
Revisit your talent. For those of you that haven’t outsourced big portions of development, make sure you have great, creative developers, build a high-performance development team, and up-skill your business analysts by putting personas and customer journey maps into their tool kit. Why? The agencies your peers use have and cultivate these skills. At minimum, you'll be in a better position to manage and maintain what they’ve put in place if you have complementary skills of your own. If you have outsourced development, we can help you make the case to bring back the right pieces.
Development leaders! Project leaders and business analysts! Application and solution architects! Want to move forward on your business technology (BT) journey and be viewed by your business stakeholders as a valuable team member? Take a tip from last week's Forums held in Boston. Embrace Business Process Management (BPM) And Customer Experience. Don't ignore them, embrace them. Why? They're essential to helping you achieve your business outcomes.
I know, I know. You read the above and now think "Gee Kyle, what's next? Going to enlighten me on some new BPM or customer experience management technology that's going to transform my very existence, my company's future?"
Nope. Let me explain....
Last week we hosted more than 250 of your application development and delivery and business process peers in Boston and focused on how to succeed in the new world of customer engagement. The most impactful discussions I heard were the side conversations we held with attendees, sometimes occurring over dinner and cocktails. We didn't discuss technology. We discussed the skills your peers were developing in two fundamental areas:
BPM - no, not the technology but the Lean and Six Sigma based methods, techniques, and tools organizations use to focus on business processes and not functions; to strive for continuous improvement; and to focus on customer value.
Customer experience - defined more eloquently by my peer Harley Manning, but I'll summarize as the methods, techniques, and tools used to understand how customers perceive their interactions with your company.
Most Forrester readers certainly understand the importance of empowering their employees to contend with highly informed and increasingly demanding customers. But I’m often asked just how to overcome the process and data integrity challenges of apps or services that empower employees and/or drive continuity of experience for consumers across channels. With the rise of mobile as well as web and call center interactions and with a proliferation of new tools for managing distributed processes and data, most application development and delivery professionals as well as their business process and applications colleagues have to absorb all the arguments before they make decisions that could be critical to their firms’ futures – to say nothing of their own careers.
One pioneer whom I interviewed was immensely proud of his lightning rollout of a guerilla app to support his firm’s front office in advising clients on complex product choices. I asked him about future plans and sheepishly he admitted they would be starting again from scratch because the guerilla app was unable to leverage enterprise services exposing critical data about product offerings. He remarked ruefully that sometimes you do have to follow the IT standards “yellow brick road” rather than just head for the hills, but wouldn’t it be great to have the best of both worlds, with both agile deployment and full advantage taken of enterprise assets and data?
If you need a deeper understanding of the issues and options, then I’d like to invite you to join us at Forrester's Application Development & Delivery Forum, where my colleague Clay Richardson and I will discuss in practical terms how to deliver integrated experiences across multiple touchpoints.