Enterprise 2.0: why it should never take three weeks to make a change to your web application


"Would you like to slow down the pace of development of your products?"

This was the question Adrian Cockcroft from Battery Ventures asked at the Nginx conference in October. The answer of course is "No". This is 2014, we see companies like Netflix can roll out changes daily and in some cases, hourly. Yet for many enterprises, it can still take weeks to add a new site or even a small new feature for the line of business. Even NASA can fly to the moon and back in less time!


Speeding up the rate at which changes are made to websites, and changes to IT systems is at the heart of Enterprise 2.0, applying lessons from startups, open source, and the leading websites to improve and accelerate how companies roll out and update their websites and other enterprise information systems.

Most enterprise IT teams are still organized to deliver monolithic system updates. If a change requires new code, it will require a number of different teams to work together -- product management, user experience, design, software engineering, quality assurance, IT operations, system administrators. All working together and coordinating the development and deployment of the new landing page as part of a site deployment this is why we wait. Coordinating up to seven teams to work together, who may operate in silos within the organization, makes for long development cycles. This is fundamentally inefficient and results in a long slow process where everyone gets frustrated.

"We’ve always done it this way" doesn’t cut it anymore, and it’s time to rethink how we approach enterprise website and application development. Companies like Netflix have proven we can move much quicker, and now it’s time for enterprises to catch up.

As Adrian Cockcroft talks about in the way that Netflix approaches application development, Enterprise 2.0’s should change the development of their applications from a single monolithic application to microservices, where each part of the application is loosely coupled and can be developed and deployed without affecting other parts of the application.

Instead of organizing IT as separate siloed teams, organize them instead into "feature teams", each responsible for designing, developing and deploying their part of the application. This approach simplifies the application, and development of the application, so new features can be deployed in days (or even hours) rather than the several-week-long deployment cycles many enterprises are familiar with.

This is also where open-source and open-core software plays a significant role. Open source by its nature is designed and developed collaboratively, by distributed teams working together. Naturally they create software that also works well for distributed teams working collaboratively.

Many enterprises today are using a mixture of their traditional software from big name vendors, together with some of the newer open source software that is designed for feature teams working collaboratively.

These new open-source enabled systems are leading the way for entirely new capabilities. Microservices enable enterprises to reuse and re-purpose content and services in their websites and web applications through authenticated APIs. The delivery tier (load balancer, cache, proxy services) are built inherently into the web applications to be truly portable and scalable -- if performance is sluggish, add additional virtual machines as web servers or caching layer. Deploy these to the cloud, in Seattle, Siberia or Sydney. For enterprise 2.0 companies, using virtual environments and micro-service based web applications, huge architecture changes like this can be done in minutes, where it used to take months.

This massive increase in speed of delivery is why many enterprises are taking the leap of faith and moving from the existing processes they have trusted to the new techniques and tools that are designed for the modern age. IT teams need to be enabled to move at the speed of business.

Image Credit: alexsvirid/Shutterstock

unnamedOwen Garrett manages the products at Nginx, Inc. NGINX perhaps needs little introduction -- the open source web server and acceleration software delivers traffic for over 40 percent of the world’s busiest websites and has built an enviable reputation for performance since its first release 10 years ago. Nginx, Inc. is the commercial company formed around the NGINX product, with a mission to build on our open source success and create complementary products and services. Prior to NGINX, Owen spent 14 years as a software engineer and lead product manager at Zeus Technology and Riverbed, developing software load balancing and application delivery technology

5 Responses to Enterprise 2.0: why it should never take three weeks to make a change to your web application

  1. Bob Grant says:

    Despite the logic in everything in this, I doubt that most of the major corporations with a web presence will change.

  2. TalGreywolf says:

    There is a major difference between making changes to a commercial website (such as Netflix) as opposed to an enterprise website (such as NASA). When you're talking about something like Netflix, you aren't necessarily as worried about the impact of your changes (although you should be). But when you're talking about applying those rapid changes to something that is a mission-critical 24/7 website or service, you certainly don't want your web designers going in and making changes without consideration of the impact of those changes. Thus the testing, the time to ensure it won't break any other application, making sure that it's 100% functional BEFORE release.

    And there are going to be businesses and agencies who cannot afford the risks of what is being proposed by Mr. Garrett.

  3. Mark says:

    I'm with TalGreywolf. Yes of course there are lots of times that as fast as possible is a good thing but equally there are many cases where it is completely inappropriate. For example I was recently dealing with some Emergency Services IT folks. Their customers are the people in the Police, Fire, Rescue, and Ambulance services.
    These systems do change but any change must be 100% reliable. Human lives are at stake. And in addition there is frequently at least some training involved for their end users. So physical / real world factors come into play as well.
    So sure - go for *development* at whatever speed you like, but keep in mind that release might not be appropriate.

  4. Akshay Mathur says:

    It is correct that coordinating with 7 individuals is faster than coordinating with 7 teams.

    However, having each roll (like designer, architect, devops etc.) in each feature team is not practically possible. Sharing resource between teams takes you back to having shared function based teams :(

    What worked for us at ShopSocially that we groomed every engineer for doing everything (requirements, design, development, UI, testing, deployment etc.). In this way, we were always had 1-2 person feature team taking a feature really end-to-end from requirements to production deployment.

    Detailed studey published by me for a conference in this regard may be read at my blog http://learningsofakshay.blogspot.in/2012/07/releasing-software-without-testing-team.html

  5. Ronnie says:

    Great article Owen. We included it in our January roundup of the best system administration, hosting, security, and enterprise IT content: http://www.interworx.com/community/best-administration-hosting-security-enterprise-from-january/. Thanks for the insight!

© 1998-2020 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.