There was an interesting panel discussion last night at the WebGuild monthly meeting. John Rowell (Chief Technology Officer, OpSource), Brad Neuberg (Developer Advocate, Google Gears), Raju Vegesna (Evangelist, Zoho), and Bill Scott (Director of UI Engineering, Netflix) gave their impressions on were we currently are on the web and the trend toward Web Apps. The trend over the last two years has been MashUps, where you build a Web App that uses information and the infrastructure of a larger application. Two common examples are small Web Apps that running inside Facebook and Web Apps that use data from Google Maps.
This trend has been gaining ground under the term Software as a Service (SaaS). OpSource and AdventNet's ZoHo are good examples. OpSource is targeting the developers at both small and large companies. They provide the infrastructure to support the Web App. The companies can now focus their resources on the product and let OpSource worry about servers, storage, security, backups, extensibility, and all the other large, complex issues that come with owning the infrastructure.
Adventnet's ZoHo product line implements both the infrastructure and the Web Apps sitting on it using this separation approach. Using a common infrastructure, web App teams only need to focus on the features and functions of their products. Each product is light weight and the development is customer driven. They only add features and functions when they are requested by the customer. The infrastructure team creates and maintains the support systems. This enables them to roll out new Web Apps and make changes to the existing Web Apps quickly.
Google is a big player in the move to open source tools and applications that make it easier to use the web. Google Gears is an application that enables you to use the data from an on-line service when you are not on-line. Basically it creates a database on the client system used to cache the data from the on-line service. When your system does connect back to the on-line service, the data is automatically synced. While a little different, it proves a developer with a toolkit to create an App that uses the infrastructure of an existing on-line service, such as Google Maps, without being part of that company.
At first, Netflix's interest in this area was puzzling. Their focus is matching movies to customers and enhancing your movie experience. They have a huge database about movies and their customers. Opening that up to outside Web App developers is not the driving factor. With well over seven million subscribers, the infrastructure extensibility and the ability to create and deploy new features are complex problems. Redesigning the system to follow the model of separating the infrastructure from the Web Apps will help them handle the current and future demands. It will also make it easier for them to move into direct distribution.
For the Web App developers and the companies that own both the infrastructure and the Web Apps, this is a great move. As on-line services and applications grow, the infrastructure complexity, cost, and extensibility have become serious issues. This model is not new. For years, the satellite designer had used a common data bus that allowed different components to plug-in and communicate. We are now seeing the concept of the web as a big data bus start to drive the thinking. The issues of costs and monetization are quietly being discussed inside the major on-line service providers. They are creating APIs to allow controlled access to their data and functions. The trend of Web App developers creating products without large and expensive infrastructure investments will continue to grow. At some point, the people spending huge sums of money on the infrastructure will a way to collect payment form those developers. If you have a closed system, like Facebook, that becomes easy. The current movement is toward more open systems and not developing more closed gardens. It will be interesting to see how the usage and payment are tracked and how the costs are allocated.
Technorati tags: web design; software management; web apps; business strategy;
Showing posts with label software management. Show all posts
Showing posts with label software management. Show all posts
Thursday, January 17, 2008
Tuesday, January 31, 2006
Software Project Management – shifting from a directed to a collaborative model
When software development started, they used the existing project management techniques. Those tools and techniques worked well for people constructing buildings, but they did not provide good tools for managing software projects. Using the standard water fall method, each step was completed, leading in a straight line to project completion. I know that this is a simple view. Some of the steps had overlaps so that the proceeding step could start before you finished the previous step. But, in general, the assumption was that all the requirements could be started at the beginning and that they changed slowly. People had thousands of years of experience interacting with and creating buildings. Not only is software a relatively new area, it is rapidly changing.
Dr. Barry Boehm published a new approach, the Spiral Software Development model, in 1988. This was a way to address the IKIWISI syndrome ("I can't tell you, but I'll know it when I see it”). In recent years, a number of new techniques have been created to address the problem of the customer not being able to give you all the requirements since they do not know all the requirements at the start of the project. Most of the techniques try to address this problem by developing what you know as fast as you can, so that you can present it to the customer. As the customer sees more of the software “functioning”, they can do a better job of clarifying the requirements. This happened in the earlier methods but was seen as “scope creep”. Due to this new information and requirements appearing late in the development, it was very costly to add the changes. That created an elaborate change management system which tried to reduce the number of changes.
The biggest change that has occurred from using the new methods is that the relationship between the project team and the customer has shifted. Instead of the project team being directed by the customer, we have shifted to a collaboration model where the project team and the customer work together. This is an important and critical change if we want to develop complex software projects that will be usable and support the business goals. The software project manager’s work shifted from coloring in triangles on a chart and driving work to fit to the plan, to that of a navigator.
As the project navigator, the job is to scan the horizon for changes, work with the customer to determine if the change impacts their goals, and then using that information to keep the project team on course. Continuous collaboration is now the key skill of the software project manager. The shift in the role of the customer means that they need to be more involved and need to work with the development team to surface decision points, eliminate undocumented programmer assumptions, and understand the trade-offs.
The current methodologies and techniques all work well in specific situations. Selecting the one best one will depend on the business culture and processes, the training and flexibility of the team members, and whether the requirements will change over the course of development. No matter which one you use, the software project manager has to keep the customer engaged and involved.
Technorati tags: project management; software;
Dr. Barry Boehm published a new approach, the Spiral Software Development model, in 1988. This was a way to address the IKIWISI syndrome ("I can't tell you, but I'll know it when I see it”). In recent years, a number of new techniques have been created to address the problem of the customer not being able to give you all the requirements since they do not know all the requirements at the start of the project. Most of the techniques try to address this problem by developing what you know as fast as you can, so that you can present it to the customer. As the customer sees more of the software “functioning”, they can do a better job of clarifying the requirements. This happened in the earlier methods but was seen as “scope creep”. Due to this new information and requirements appearing late in the development, it was very costly to add the changes. That created an elaborate change management system which tried to reduce the number of changes.
The biggest change that has occurred from using the new methods is that the relationship between the project team and the customer has shifted. Instead of the project team being directed by the customer, we have shifted to a collaboration model where the project team and the customer work together. This is an important and critical change if we want to develop complex software projects that will be usable and support the business goals. The software project manager’s work shifted from coloring in triangles on a chart and driving work to fit to the plan, to that of a navigator.
As the project navigator, the job is to scan the horizon for changes, work with the customer to determine if the change impacts their goals, and then using that information to keep the project team on course. Continuous collaboration is now the key skill of the software project manager. The shift in the role of the customer means that they need to be more involved and need to work with the development team to surface decision points, eliminate undocumented programmer assumptions, and understand the trade-offs.
The current methodologies and techniques all work well in specific situations. Selecting the one best one will depend on the business culture and processes, the training and flexibility of the team members, and whether the requirements will change over the course of development. No matter which one you use, the software project manager has to keep the customer engaged and involved.
Technorati tags: project management; software;
Subscribe to:
Posts (Atom)
