In this article, explore the future of software development. Learn how today's trends might shape or split the industry.
Before predicting the future, though, let's first take a glance at the life of those who buy software development services. If you’ve read about chief information officers (CIOs), you know that their most important job these days should be to offer solutions to business problems with a price that makes it worthwhile. They are not only solving technology problems, but are also solving business problems or business goals with technology. In addition to determining basic information communication technology (ICT) infrastructure, CIOs are also finding solutions that support or enable growth, change, product launches, and so on. You could say that the role of the CIO is more business oriented than IT oriented, or at least it should be.
In the past 10 years, the cost and time demands for software development projects have tightened, and it is obvious that the trend will continue. On both the customer and provider side, it's very important to always remember the problem that you’re solving. If software developers focus too much on the technology, they can lose touch with customers (and the problems they're trying to solve). On the other hand, focusing only on the customer problem can lead to losing touch with evolving technologies and methods. Either extreme is bad for the customer in the long run. It’s mainly a question of finding the right balance.
In this article, learn how software development has evolved and how it might change in the future. Review recent trends of price sensitivity, multilocation projects, outsourcing, important technologies, and methods. Discover how the trends might push half of the profession into application building.
The future of software development looks very interesting as tools and methods evolve. Some types of projects get outsourced, and others are done in-house. Large development companies use outsourcing centers in more affordable countries where experts are available. Some companies move only the implementation and testing and still do analysis and project management locally. Others, whose customers have made the requirements specifications, can do most of their parts of the project in the affordable locations.
Large development projects are now sometimes done on the other side of the world. This sets up huge demands for the project management, development, and communication tools used by the team. For years the software industry and university researchers have invented and crafted development processes, methods, and project management techniques to ensure that development projects run smoothly even if team members are all over the world.
Customers and development companies are trying to make the software development process more efficient—and to cut costs where possible. The project management, analysis, and requirement specifications are hardest to move to locations away from the customer, because typically the requirements can only be written or gathered together with the customer.
Thus far, the actual design, coding, and testing of software have been the easiest parts of the process to make cheaper by moving them to affordable locations. In the near future, it will become more important to save time and expenses by reusing code, components, and architectures. If you read the trade press, this should be happening right now. Sometimes, though, the reality is different. Using efficient development tools, component libraries, and methods such as model-driven architecture (MDA) would make work more efficient, yet some companies and developers are hesitant to adopt these tools. There is a short-term cost, and learning curve, to make the change from old tools to new ones.
The technologies that your components use are becoming more and more important. For example:
- For a typical Java™ EE project, there are several ways a team could build the software. The do-it-all-yourself team would first spend time with the customer to write a requirements document for the first couple of iterations (depending on the development process they're using). They would then build the database manually, write classes to handle object-to-relational mappings, write the business logic with JavaBeans, and create the user interface with JSP or JSF.
- The more tool-aware team would first model the requirements with a modeling tool, and continue to model the requirements into test cases and the software architecture. They would export their models to source code in a way that is suitable for the application sever and the portal product that they’d use. Instead of manually composing the Web user interface, they'd use portal components and allow the portal to handle most of the basic stuff. They would save time, make the software less prone to errors, and make the application’s design and test documentation more easily changeable.
You can see there is a difference. The lessons are:
- Keep up with what's new and always try to improve your methods.
- Tools make manual work phases easier. Aim to completely remove the need to interfere manually.
So far, one of the solutions to make development services cheaper has been to move the work to cheaper locations. But technology is also another way is to make your services more efficient.
What technologies are most likely to take us to the next level? All component-related technologies, including Web services and other Web-based components, code generation, open interfaces, and more. There are several component technologies available for almost all development platforms and languages, some more famous than others. They all aim to reuse code and logic, and to enhance ease of use. Some have succeeded in their goals better than others, but they all help lead the way.
Web services and other Web-based components bring the same kind of concept to the Internet. MDA lays a good foundation for generating code from the design model of the application, thereby reducing work efforts, and ensuring quality and maintainability. MDA has not broken through yet, possibly because developing an application using MDA is quite different from coding it manually, and there are different tools. Generally speaking, it is becoming more common to generate some part of the application, such as class skeletons, from Unified Modeling Language (UML).
Customer needs, trends in software development, and some of the available technologies will provide a pretty interesting future for software development.
Combining some of the methods and technologies discussed in the previous section can create an interesting setup. If certain functions are made available as a component over the Internet, either as Web services or with another technology, the role of software developer could change to service developer. The services would then be used to build applications for end users by combining several small components into one big application. People who use the services would be application builders. The service developer and application builder could be the same person; think of them as roles.
Web services standards provide tools for offering interfaces and the role of broker of services (UDDI). However, the critics say Web services are too complex as it is. The RESTful Web services (with Web Services Description Language) could make it easier though.
Small software companies could focus on developing and maintaining specified services. As customers try to find ways to implement software more cheaply, the evolving setup would serve them well. With a good selection of services, building applications based on the services would quickly become an obvious choice. It would be tempting to offer affordable applications to customers within a tight schedule. The customer relationships would become stronger, and a good reputation would ensue. Demand, and a promise of money, would lure developers to build and offer these services.
Services could range from simple graph building operations to managing a complete sales process. Application builders would be able to select the most appropriate services, and build the application while crafting the architecture of the application. Even with a thorough requirements analysis phase, test phase, and customer-specific user interface development, the work efforts of the project would be minimal compared to a typical development project. Of course, this is just a prediction; the process could be different but the basic elements should be there.
Developers and companies would then divide into two main groups: one creating services, and one creating customer solutions from the services. At first there probably wouldn’t be much competition between services, but once (and if) the model started to work, competition between the services would be fierce. The builders could easily, from a technical point of view, change a not-so-good service into a better one.
One group couldn't work without the other. Some of the Web application providers (customer relationship management, enterprise resources planning, project management suites, and so on) could possibly start to offer their applications using Web interfaces for other developers. This is already happening, but what is still needed are easier-to-use interfaces that are similar to one another, and simple contract issues between service developers and application builders.
The future requires a development environment that combines requirements, modeling, and building applications from the services that are available. A tool could also solve the contract issue with a simple solution, such as a check box to make contract issues easy for the application builder. Evolution of tools has been continuously fast for years, so if the speed continues at that rate, the required functions could be available in the near future. Envision the tool as a Delphi, or Microsoft® Visual Studio, with component libraries of services offered online.
This column ruminated on the future of software development. The evolution of tools and methods in the past 10 years has been amazing. Source code that used to be written manually can now be generated from the UML model, letting developers focus more on the essentials. Services and components can be made available over the Internet. Project management methods and development processes have made multilocation projects easier to handle.
Customers want customized solutions faster, and for less money. By combining some of the trends discussed in this article, one can predict that the software development industry might split into two groups: developers who develop services and host them for others, and application builders who use the services to build applications for customers.
Learn
- Wikipedia
has information about model-driven architecture, including a good
list of references.
- Read about Web services on Wikipedia.
- Read developerWorks articles about Web
services:
- "Design and develop JAX-WS 2.0 Web services" (developerWorks, Sep 2007)
- "Web services hints and tips: JAX-RPC versus JAX-WS, Part 3" (developerWorks, Jun 2007)
- "Best practices for Web services: Part 1, Back to the basics" (developerWorks, Oct 2002)
- "Web services insider, Part 1: Reflections on SOAP" (developerWorks, Apr 2001)
- Read developerWorks articles about MDA:
- "An introduction to Model-Driven Architecture (MDA)" (developerWorks, Apr 2005)
- "Architectural manifesto: MDA for the enterprise" (developerWorks, Jul 2005)
- "Architectural manifesto: The MDA adoption manual" (developerWorks, Aug 2005)
- Get an
RSS
feed
for Mikko Kontio's Architectural Manifesto column.
- Browse the
technology
bookstore
for books on these and other technical topics.
- In the
Architecture area on developerWorks,
get the resources you need to advance your skills in the architecture
arena.
- Find resources to help you architect enterprise and software systems in
free IT architecture kits from IBM.
- Stay current with
developerWorks
technical events and webcasts.
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware
products from IBM® DB2®, Lotus®, Rational®,
Tivoli®, and WebSphere®.
Discuss
- Participate in the
IT architecture forum to exchange tips and techniques and to share other related information about the broad topic of IT architecture.
