Industry voice: Don't let your app choke during development: use a RAD solution

Every day we hear that IT teams are under growing pressure to deliver an ever increasing number of apps. Managers and executives want to see immediate results without understanding the amount of work that goes into coding an application by hand.

Research shows that 48% of UK businesses have a backlog of 10-20 apps stacking up because they can't keep up with the current level of projects, let alone get on top of them. However, many of these delays come from simple chokepoints in the process that can be easily resolved.

Initially, at least, the chokepoint in application delivery appears to be the development team. Months pass as the backlog grows, and the business demands to know why apps haven't seen the light of day. Half of those surveyed (50%) said the main challenge they faced was the time it was taking. Hand coding an application for one mobile platform can take weeks, even months – never mind coding it for multiple platforms.

Organisations try to solve this problem by automating manual coding processes with rapid application development (RAD) tools. And it helps – to a degree.

RAD tools enable development teams to build applications faster so they can move on to the next project. But it doesn't solve the ultimate goal – getting applications to customers faster – because applications must still be tested and the infrastructure configured. None of this is fully automated. The plethora of tools available for trying to implement continuous integration and continuous delivery must be manually configured and integrated using scripts. So now operations becomes the chokepoint in application delivery.

But the problem doesn't end there, either. In some ways, it only begins when the application goes into production. As soon as they begin using an application, users have the expectation that improvements will be many and often. This puts the onus back on development to improve the mobile experience, deliver new functionality, and fix bugs on existing mobile apps – in addition to developing new ones. The bottleneck has now come full circle.

The key to preventing these bottlenecks is to consider the application lifecycle as a whole. In addition to accelerating the development process using a no-code platform, IT organisations should automate the entire delivery process as well – from development, through test, and into production.

A solution that combines all of these into one Rapid Application Delivery platform ensures that no single point in the application lifecycle becomes a chokepoint. A RAD platform that understands the dependencies between all apps and infrastructures can cleanly automate, verify and govern the delivery backlog with single-click speed and efficiency.

Automating the entire application lifecycle also helps IT organisations transition to and embrace a DevOps culture. Because Development and Operations teams don't talk to one another, share the same goals, or use the same tools, DevOps can become particularly challenging when it comes to change management.

A RAD platform addresses these challenges. One platform controls the entire change management process, making it simple for Development and Operations to have a role inside of the platform and limiting potential errors that result in a failure. In short, a RAD platform facilitates DevOps efforts without increasing risk.

A RAD platform offers another interesting benefit. It can actually increase application adoption. There are often times when users will open an application, use it once or twice, and then decide whether to continue to use the app based on whether it is updated regularly. Users will stick with even a mediocre mobile app if they know that it is updated frequently and continually improving.

To successfully deliver and implement a modern application, organisations must consider the app's entire lifecycle. Pushing an app out the door as quickly as possible with no thought to how and when it will be updated is simply creating another chokepoint. A RAD platform can help with this but only if it is used in the right way.

Instead of automating development at the cost of operations, focus on the ultimate goal: creating an app the consumer wants to use. Combining a DevOps mind-set with a RAD platform that automates the entire lifecycle can do just that.

Zahid Jiwa is VP of sales for UK and Ireland for OutSystems

View the original article here

Industry voice: Call for backup: why backing up data should be like brushing your teeth

When it comes to data protection, most people don't have a clue. Many do not take the time to perform regular backups and far more have never even considered doing a backup. In a world where the amount and value of information is constantly increasing, backing up data should be as natural as brushing your teeth twice a day.

We live for about 70 years, or 613,200 hours. If you subtract time spent sleeping, we have 408,800 hours left. If you take into account our first 16 years when we're not very productive, we're left with approximately 315,000 productive hours.

So wasting five or 10 hours recreating files due to data loss can take its toll. Many can empathise with losing digital photos which haven't been backed up. The only way to recover a similar image would be to organise a photographer, restage the scene and retake the photo. This could quickly add up to 15 hours, while recreating a video could take days if not months to complete. It's much faster and easier to get in the habit of backing up data instead of suffering the loss of time rebuilding and recovering lost data.

Despite this, there are still businesses which don't take data protection seriously. The situation is similar to skipping regular medical check-ups or failing to visit the dentist – until a person is very sick, they don't think about it. People are reactive and with that comes serious risk. An examination can save or extend your life and backing up data can save businesses and consumers from suffering the grave consequences of data loss.

Large corporations understand the importance of frequent backups. Saving and archiving their data is built into their everyday routine. Medium-sized companies tend to protect the most important portions of their data, while small companies back up almost none of it. It doesn't even cross the minds of most consumers to back up their personal data.

To put it into perspective, imagine what would happen if a bank suddenly lost all its data. It would immediately go bankrupt. The same thing would happen to insurance companies, financial institutions, and any businesses consumers depend on. Even at restaurants, a large amount of information is stored electronically, such as credit card details, credit histories, and table reservations. Losing all that data would cause immense disruptions in business. And what if the data for an aircraft were lost? It would no longer be able to fly.

Large companies understand the risks and constantly make redundant backups and archives. Photographers, artists, musicians and designers are all professionals whose work is closely dependent on storing digital information so backing up their data is automatic. The highest quality data protection techniques don't stop with backups, they also extend to encryption to ensure privacy. As companies or individuals produce more copies of their data, they are inevitably diminishing the level of security by creating more entry points.

Furthermore, professionals backing up offsite may store their data on third-party services and if they rely on tools with little or no encryption, they are providing direct access to anyone on those servers. Nobody wants someone else to know everything about them, but storing private information on the internet or with a service is no different.

We leave ourselves and our information open to coercion by offering the service companies the opportunity to collect it all and (according to the service agreements) own it all. It is important to understand that data protection doesn't stop at a backup, but continues to encryption and managing storage.

It is vital our generation becomes data savvy, to develop a good sense of how to work with data and preserve our privacy through independent backups. Information is arguably our most important asset. While most of the other "valuables" in our lives depreciate and quickly become outdated – gadgets, houses, cars – critical data will never be obsolete. So as you plan for your businesses future, ensure data protection plays a key role in how you work or risk huge losses down the line.

Serguei Beloussov is CEO of Acronis

View the original article here

Industry voice: Don't Backoff: nail down your remote access policy or face the music

Remote access and security worries go hand in hand, and last year, we saw the likes of the Backoff malware targeting point-of-sale terminals, and updated Citadel malware, both leveraging unsecured remote access systems to gain access to networks.

For security professionals, the temptation to switch off remote access must be high. However, remote access technology is an essential tool for IT departments and third-party service providers to manage, update and troubleshoot remote systems. The issue isn't remote access technology itself, it's that these technologies are often not managed closely, if at all.

When implemented and managed properly, remote access can be secure. However, as IT professionals, it's important to look at how to govern it. Are the right policies in place when it comes to remote access by IT or third-party providers?

To start with, let's review some best practices. These apply whether the person accessing your network is an internal employee, an outsourced service provider, or third-party vendor.

First, consolidate remote access tools so you can centrally manage and monitor all insider and external remote access. Once you have everyone using a single, sanctioned remote access solution you can categorically block all unsanctioned tools so they can't be used on your network.

Multi-factor authentication is a must. But in order to implement MFA, each individual must be using unique login credentials. Often IT teams or vendors share generic logins to save money on licenses, making it easy for attackers to use brute force methods to successfully guess the password. Not only does sharing passwords undermine access security, it makes it impossible to audit who is doing what on your systems.

Speaking of weak passwords – complexity of passwords, password length and enforcing regular changes in credentials can all help to decrease the potential of an attack.

Finally, limit access to only the specific systems and timeframes required while capturing full audit trails of all remote access activity. This way you can review what occurs during each remote session, and what actions were taken by the technician. This allows you to know exactly who accessed what systems and what they did.

Last year, we all saw the impact that unsecured remote access implementations can have on businesses. One of the reasons that attacks are successful is that there are rules in place for employees using remote access technologies, yet these same rules may not be applied to external parties providing IT services.

For many companies, outsourcing and third party access to their network is a given. 88% of companies have at least one third party with access to their IT networks, according to research by Ovum. One of the respondents had more than 100 service providers using remote access to enter the corporate IT network.

Whether you have one outside supplier or 100, how do you monitor and manage their access? If they are using old or legacy remote support tools, they may be leaving unnecessary vulnerabilities or backdoors on your network that are easy for attackers to compromise. Alongside centralising and prescribing remote access tools, shutting these backdoors should be a given.

Over and above the physical remote access connection, it's also important to consider the rules and policies that people have to follow. This may include setting up a separate set of rules for outside providers that they have to follow as part of working with the organisation. For example, an IT outsourcer should be allowed to access your systems from his computer on his company network, but not from his iPad at home or outside standard business hours.

Security has many layers, and no one solution is going to fully protect you from a data breach. But if you can lock down the initial entry pathway just a bit more, you can significantly up your chances of keeping hackers out and your sensitive data in. With the right mix of tools and processes, threats and malware targeting your company network can be kept at bay.

Boatner Blankenstein is Senior Director of Solutions Engineering for Bomgar

View the original article here

Industry voice: How to price up an agile project without dooming it to failure

We're all used to quoting and procuring waterfall development contracts, where a defined set of requirements is delivered for a defined price. Because the outcome is clearly set out at the start, it is relatively straightforward to estimate and validate the effort and cost. But how do you price when you don't know exactly what it is that you'll be delivering? This has become one of the biggest challenges around agile projects, and one that doesn't have a simple answer.

The flexible and changeable nature of agile means it doesn't lend itself well to fixed price, yet many procuring organisations still want the certainty of knowing what they'll get and how much they'll pay. This is closely linked to the fact that many organisations want the benefits of agile, without fully understanding what's needed to achieve them.

A prime example of where this went wrong last year is the UK government's Universal Credit programme, which attempted to use agile, but wasn't supported by the right structures, processes and contracts that would have helped make it a success.

The reality is that while agile has matured over the last decade, these processes, structures and contract types have lagged behind. Organisations that understand the requirements for successful agile projects will also understand that agile and fixed price contracts don't go well together, but until this sentiment is shared across an entire organisation, businesses bidding for agile contracts must be flexible in their pricing method. At the same time, all involved – in procurement and delivery – must understand the implications of each approach.

Time and materials (T&M) is ideally suited to agile projects, because it acknowledges the complexities of software development, in that you can't always easily foresee how much time something will take.

The drawback, from a procuring organisation's point of view, is that they, rather than the supplier, shoulder the overall risk in terms of budget, time, effort and scope. However, because agile projects deliver working software that provides real business value at the end of every iteration, the procuring organisation can halt a project at any time and still enjoy tangible benefits. And, of course, the procuring organisation has full control over which benefits these are, because it is their Product Owner who selects what is delivered in each iteration.

In this respect, agile is less risky than waterfall, where an aborted project (of which there have been numerous high-profile examples) may deliver no obvious benefit.

Having said this, the key challenge with T&M contracts remains that the procurer doesn't have a clear view of the costs being incurred by development. To overcome this, there are some alternatives to pure T&M that can be used in agile projects.

Time-boxed time and materials, sometimes called 'fixed price, fixed effort', is compatible with agile insofar as it enables a project to evolve, while giving the procurer the peace of mind they require over cost control. What it doesn't necessarily provide, however, is a clear idea of the outcome that will be delivered in that fixed time period.

Agile projects can be delivered for a fixed price, thereby shifting the risk from the procurer onto the supplier. However, this approach, while it may appear attractive to procurement departments, will limit the benefits agile can deliver. For example, a fixed price contract is likely to specify requirements up front, which limits the scope for changes during development – one of the key factors that helps make agile a success.

Having said that, there are examples of successful compromise projects, where requirements have been specified up front, and the customer has paid a fixed price for a fixed set of requirements, alongside a pool of funds for additional features, which could be added or removed as the project evolved and business needs changed. The entire project is then delivered in a series of agile iterations.

It's not unheard of to run parts of a nominally fixed price waterfall contract in an iterative, agile-esque way. This may bring certain benefits of agile development, such as test-driven development and continuous integration.

However, a fixed price/waterfall project is unlikely to offer very much scope for ongoing feedback, nor for iterative changes to the requirements along the way – the two things that are central to an agile project. Indeed, some would argue that this is not agile at all, but is merely borrowing some techniques that are used in agile.

Every pricing model has advantages and drawbacks, but the most important thing to consider is the outcome: which model will give the best chance of the project delivering the desired result? If organisations really want the benefits that agile can provide – notably that they ultimately get the system that genuinely addresses the underlying need, rather than the system they think they need at the start – then the best pricing model is time and materials.

If, for whatever reason, an organisation is required to deliver an agile project as part of a fixed price arrangement, this needn't be a deal-breaker, but it's important that both the provider and the procuring organisation understand and accept the limitations that a fixed price contract can place on agile.

Sue Purdin is Sales Director at IPL

View the original article here