Google sets amazing new standards when it comes to web, mobile, and cloud technologies. That's why we are here at Google I/O 2013 in San Fransciso to find out what new technologies and tools developers can expect on all technology fronts. See this special edition of Forrester TechnoPolitics to experience the energy of Google I/O.
There is a scene in the Broadway hit Spamalot in which a peasant jumps up from a cart of corpses and vigorously complains that he's "not dead yet". It's a humorous side-story to the main theme of the search for the Holy Grail. One might be accused of thinking of COBOL in the same way, as a side-story to the current major themes of mobile and web development, or perhaps as a historical footnote to the current narrative. IBM's recent announcement of major upgrades to its COBOL compiler technology provides a good reason to pause in our headlong pursuit of the latest technology to reflect on the value of COBOL applications in enterprise software portfolios.
While mobile and web technologies often garner everyone’s attention, the reality is that most organizations that have been around for more than 30 years still run their core business processes using systems that were written in COBOL. Anything that makes these apps easier to evolve and extend is a very good thing. The reality is that evolution and extension of these apps is critical to business success. In order for the flashy-new-social-networking-enabled mobile and web Systems of Engagement to succeed, the workhorse Systems of Record and Systems of Operation are going to have to evolve apace. This means that they must take advantage of the latest architectures as well as being refactored and modularized to align with a service delivery model.
Banks have a reputation for being stodgy and conservative. But Credit Agricole (CA) has broken the stereotype. I had a great discussion a few weeks ago with Bernard Larrivière, Director of Innovation, and Emmanuel Methivier, the CA Store Manager, about the CA Store launched last fall. The store houses new services developed by third-party developers using the bank’s secure customer data — one small step for CA, one giant step for the banking industry and the data economy.
The CA Store was not only inspired by the Apple Store model but also by government open data initiatives. The public sector provided the model of exposing APIs to internal data and working with independent developers to encourage application creation. However, in a move that will likely be carefully watched by their public sector brethren, CA recognized the need for a better business model to incent developers to use the data, and to sustain the development and maintenance of the applications.
Business leaders have revenue growth first and foremost on their minds. On average, 70% of these business leaders place a high or critical priority on revenue growth, customer acquisition and retention, and addressing rising customer experience expectations for 2013. Our data suggests business leaders are 50% more likely to identify these as critical initiatives than they do margin improvement or reducing operating costs. Growth and customer experience improvement take business priority.
Rowan Curran, Research Associate and TechnoPolitics producer, hosts this episode to ask me (your regular host) about The Pragmatic Definition Of Big Data. Listen (5 mins) to hear the genesis of this new definition of big data and why it is pragmatic and actionable for both business and IT professionals.
Podcast: The Pragmatic Definition Of Big Data Explained (5 mins)
One-Size Software Development Methodologies Do Not Fit All
Dozens of software development methodologies exist, from waterfall to Agile to pure anarchy (Agile has always rubbed me wrong). Mark Kennaley speaks the truth when he says that “there is no ‘best’; there’s only contextual fitness for purpose.” Mark is the founder of Software Development Experts, a software development methodology historian, a consultant, and the creator of an expert system that helps organizations determine the best software methodology to use based on 10 factors: development team size, domain complexity, technical complexity, the geographical dispersion of the development team, time-to-market pressure, enterprise specialization, contract relationships, compliance, criticality, and culture. This makes perfect sense, and so does Mark. Unfortunately, entrenched dogma and high ceremony can obscure what really matters.
Composite, Dynamic Software Development Methodologies Are Best
TechnoPolitics speaks with Mark about how firms can choose the best methodology based on the 10 factors that matter. One size does not fit all. Listen to find out why and how to move forward.
Podcast: One-Size Software Development Methodologies Do Not Fit All
The CRM solution landscape has experienced considerable change, including significant vendor consolidation and a rapid rise in the popularity SaaS solutions — often referred to as "CRM in the cloud." Organizations adopt SaaS CRM solutions because of low upfront costs, good usability, proven scalability, better flexibility, and faster time-to-value compared with traditional on-premises applications. Forrester surveys indicate that nearly 70% of organizations are interested in, or are currently using, SaaS solutions for horizontal business processes such as CRM and HR.
But clients tell me they cannot capture the promised benefits if they do not have certain prerequisites within their own skill sets, such as the right developer talent and governance model to work in an agile, iterative approach that leading organizations use to be successful. This is not your father’s CRM anymore, so don’t make these mistakes:
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.