1. Executive Summary

The report examines systems development and implementation with focus on the software value chain. It analyses the impact of marketplace issues on software design and the ways and means to create value for the customers. It takes a look at object oriented software development, a modular software development technique that has been widely adopted. It views the future trends in software development and the pros and cons of making, buying or renting software. Finally, it examines the two ways of implementing systems and their relative merits and demerits.

2. Sources of value for the user

The primary purpose of software is to serve the needs of its end users. Some of the generic value factors from the perspective of the user are as follows

* Productivity and impact – The tangible impact an application has on the organization such as improving productivity, reducing time to accomplish tasks, better management of knowledge assets etc.

* Network effects – The increase in value of the application with the increase in number of users that use the application.

* Usage – Higher the usage (more number of users and more use per user), higher the value.

* Quality and performance – Defects observed in the system, the volume that the system can handle and its response time are some of the factors.

* Usability – Users’ perception of how easy it is to use the application

* Flexibility and extensibility – Flexibility in meeting changing requirements is valued, especially in business applications.

* Composability – A single closed software solution offers less value than one that can be combined with other solutions to achieve greater functionality. This is called the composability of complementary software solutions.

3. The software value chain

3.1. Applications and infrastructure

The most fundamental architectural concept in software is the decomposition into application and infrastructure. With some notable exceptions, firms in the industry generally specialize in one or the other. The core competencies for providing applications and providing infrastructure are different. Applications focus the value proposition on end users, and infrastructure provides value primarily to application developers and to operators. Applications are valued most of all for functionality and usability; their performance and technical characteristics are more dependent on infrastructure. It is advantageous to move as much technical capability to the infrastructure as possible, so application developers can focus on user needs. Considering the separation of application from infrastructure, there are two supplier value chains as shown in the figure below.

3.2. Industry organization

Since companies tend to form around individual units of value that enhance internal synergies and exploit common expertise, industrial organization can be thought of as a partitioning of the value chain into distinct companies. In these terms, there are natural businesses formed by partitioning of the value chain as shown in the figure below

The application software supplier typically bundles the analysis and development functions, working closely with the end-user organization to define requirements.

The infrastructure software supplier must be cognizant of the requirements imposed by a wide range of applications. The system integrator specializes in provisioning. This role takes responsibility for acquiring software from both application and infrastructure suppliers (usually more than one), does whatever is necessary to make it work together, and installs and tests the software. Some programming is typically involved as well.

Another role in provisioning is the consultant, who helps the end-user organization rework the organization and business processes around the software, and often helps configure the software to the needs of the particular end-user. Operation is the specialty of a service provider. An application service provider (ASP) licenses and operates the application, while an infrastructure service provider (ISP) purchases or licenses and operates the hardware and software infrastructure (computers, storage, network, operating system, etc.).

4. Modularity in software development

Modularization is a mechanism for improving the flexibility and comprehensibility of a system while shortening its development time. Modularization has three purposes from an engineering perspective

* To make complexity manageable

* To enable parallel work

* To accommodate future uncertainty

The benefits of using a modular approach in software design are as follows

* Modules are easy to replace

* Each module captures one feature of the problem, so aiding comprehension (and hence maintenance); as well as providing a framework for designing as a team

* A well-structured module can easily be reused for another problem

The successful use of modularity should be reflected in quality characteristics, including: maintainability, testability, usability, and reliability.

There are two distinct approaches to modular software development. In decomposition, modules are defined in response to the required system functionality, and in composition, that functionality is achieved by composing pre-existing modules. Composition is the focus of component software. Components are reusable modules suitable for composition into multiple applications. Components can retain their identifiable individuality in a deployed application, allowing the application to be updated and extended by replacing or adding components.

The costs of modularity include

* More effort and investment may be needed for a well modularized design

* There is an overhead introduced with layering

* There might be excessive capability due to standardization

4.1. Appropriation of value

Layering is a specific architecture in which modules share a vertical relationship: Each layer is dependent on the layers below. The layers are thereby complementary, and all layers are necessary to support an application. The figure below shows an example of infrastructure layering.

The layered architecture has profound implications for industry structure. Specialization tends to occur at the individual layers, rather than being associated with narrower classes of applications. This moves away from vertical integration and towards horizontal integration, and no single company can provide a complete integrated solution to the customer. Competition forms at the individual layers, and customers (or a system integrator or intermediary) must integrate products together for a complete solution.

4.1.1. Value for customers and end-users

Customers resist large monolithic applications which minimize the customer’s integration costs but also constrain functionality and incur greater switching costs. Modular software if accompanied with the option for matching and mixing products from different suppliers provides an alternative. Modular software provides higher flexibility and extensibility to meet process differences and variations.

4.1.2. Value for suppliers

Suppliers can reduce their development costs by investing in components that can be reused in multiple applications. Modularity in software creates value in the form of real options to improve a system by experimenting with new implementations and substituting any superior ones that are found.

4.1.3. Value for systems integrators

Systems integrators add value by assembling components into systems and provisioning the application.

4.1.4. Pricing

Modular design is essential for two pricing strategies for extracting value.

Value pricing or price discrimination involves segmenting customers into groups and charging different prices. A common approach is creating different product variants and let customers self-select based on their willingness to pay. The design must allow different combinations of features and performance sets.

Bundling involves packaging different software products or feature sets to sell as a unit. In anticipation of bundling, the design of individual products-both internal and external -should anticipate opportunities to compose its constituent products.

4.1.5. Increasing vendor cooperation

Encouraging complementary solutions from other vendors increases value, although with little differentiation from competitors who can exploit the same complements. Two ways to encourage complementary solutions are standardization and APIs. Open APIs invite extension through complementary products or context-specific add-ons by the user. However, they also cede market share in the interest of encouraging innovation, broader choice, and customization. An API creates an implicit, long-term obligation for customer support. Proprietary solutions offer greater opportunity for innovation and differentiation from competitors but cause customer concern about lock-in and fewer complementarities. Standardization ensures interoperability with complements and is popular with the customers. However it increases competitive pressures as it gives the customer an opportunity to mix and match solutions from different suppliers.

4.1.6. Costs

A supplier’s costs include first-copy development and testing, distribution, customer support, and recurring development. Three important market-related cost factors are platform and distribution, recurring costs, and reuse and multiple uses. An application-as-service business model eliminates the customer’s platform dependency. The model reduces the supplier’s development costs by reducing or eliminating the number of heterogeneous platforms that must be supported. In addition, the model reduces the customer’s costs by shifting user support from software supplier to service provider.

A supplier can reduce development costs through code reuse or buying/licensing components.

5. Object oriented software development

Object oriented software development is a paradigm that supports modularization and reuse. It views a system as a collection of self-contained objects which include both data and processes. The objectives of object oriented development are

* Build objects as individual pieces and then put together to form a system. They can be reused over and over in many different systems without affecting other components.

* Allow analysts to break a complex system into smaller, more manageable components, to work on the components individually, and to more easily piece the components back together to form a system. This modularity makes system development easier to grasp, easier to share among members of a project team, and easier to communicate to users who are needed to provide requirements and confirm how well the system meets the requirements through the Systems Development Life Cycle (SDLC).

* Allow creation of reusable pieces that can be reused in other systems or as starting points for other projects.

The adoption of object oriented methods was facilitated by Rational Software by the introduction of the Unified Modelling Language (UML). UML provides a common vocabulary of object based terms and diagramming techniques that are rich enough to model any systems development project from analysis to implementation. A variety of Computer Aided Software Engineering (CASE) software tools are available in the market for supporting UML. Rational Software also created a methodology called Rational Unified Process (RUP) for applying UML. RUP is a rapid application development approach and emphasizes iterative and incremental development and prototyping that undergoes continuous testing throughout the life cycle of the project to bring the system closer and closer to the real needs of the users.

6. Components based software development (CBSD)

CBSD shifts the emphasis from programming software to composing software systems. Implementation has given way to integration as the focus. At its foundation is the assumption that there is sufficient commonality in many large software systems to justify developing reusable components to exploit and satisfy that commonality. A software development company should invest in components that have heavy reuse potential.

7. The future of software development

“The best way to predict the future is to invent it” – Alan Kaye

The history of software development is characterized by rising levels of abstraction.

Languages have evolved from assembly to COBOL to C to C++ and Java.

Platforms have evolved from hardware to BIOS to OS to Middleware to getting Domain-specific. The processes have evolved from the waterfall approach to spiral, iterative and agile methods. The architecture has evolved from procedural to object-oriented and service oriented architectures. Software will continue to become increasingly complex. The unwired Web will have far-reaching implications. The new economy requires software that can be continuously updated. The future would continue to demand high quality complex products in internet time. Following are some of the technology initiatives for software development.

7.1. Grid computing

Grid computing is a web-based operation that will allow companies to share computing resources on demand. Simply put, grid computing uses more of a server’s computing power. Today’s computers, like human brains, typically operate at only a small percentage of their capacity; they often sit idle as a processor waits for data. On the grid, the idle time of hundreds — even thousands — of servers can be harnessed by any customer needing a massive infusion of processing power. Just as the electric grid provides power to the consumer, the computing grid distributes all sorts of computing resources to solve problems. In the process, a grid can give rise to “virtual organizations” — ever-changing groups of individuals and institutions exploiting the resources of the grid for a variety of purposes, much the way that individuals in the same household exploit electricity for their own needs.

7.2. Software as a utility

Software vendors are promoting web services technologies with the idea of providing IT services as utilities which a customer pays for, based on his use. This is similar to usage of electricity. We pay only for what we use and do not own the infrastructure. Web services also have the promise of interoperability.

7.3. Pattern-centric development

Pattern-centric application development enables effective collection and reuse of technical know-how obtained during object-oriented application development, increased development efficiency, and increased extensibility and maintainability of applications. Patterns are techniques for explicitly defining and sharing technical know-how. Systematic implementations of this approach in the development of package software have shown that it enables us to not only increase development efficiency but also develop easy-to-understand, extensible, and maintainable applications.

7.4. Aspect oriented programming

The latest methodology supports a new unit of software modularity that crosscuts traditional boundaries. Aspect-oriented programming (AOP) is the latest methodology to support a new unit of software modularity: aspects. Aspects are elements such as security policies and synchronization, optimization, communication or integrity rules that crosscut traditional module boundaries. At design time, a typical AOP scenario separates aspects from the classes and methods that make up application components. A code weaver (an interpreter, compiler or pre-processor) then produces the extended classes in which aspect functionality intertwines with application components in a specific target programming language.

8. Build, buy or rent?

An end-user organization that is acquiring software for internal purposes has several options. Generally, these can be summarized as make, buy, license, and subscribe. Each has its advantages and disadvantages.

In the make option, all four stages (development through use) are kept in-house. This has the greatest potential for competitive differentiation, but offers no potential to amortize costs over multiple end-users, and invokes considerable delay and risk. The buy option is to outsource development to a firm specializing in such developments. In this case, the source code may become the property of the end-user organization, and ongoing maintenance and upgrade may be the responsibility of the developer or user. Both options offer the opportunity to mold business processes, organizations, and the software as a unit, gaining efficiency and competitive advantage. In the license option, an end-user licenses a software product from a software supplier. Finally, in the subscription option, the application services are provided by an ASP. These are generally low-cost options, but offer little opportunity to differentiate from competitors. In both cases, the software largely defines business processes and organizations, and a consultant is frequently engaged to assist in making needed changes to processes and organizations. Infrastructure is rarely made or bought, but can be licensed or subscribed.

8.1. Economic considerations

Apart from strategic considerations, some of the economic considerations involved in making the decision to make, buy or rent applications are:

* Reduced costs of ownership and operations – Renting from ASPs saves money spent on administration, support, maintenance, upgrades and deployment. Through the application serving model used by ASPs, organizations can extend the useful life of legacy devices, avoid having to increase bandwidth capabilities, reduce application management costs and eliminate the need for installing servers and other hardware in remote locations.

* Fixed and variable costs – In ASP model the fees are based on usage (e.g. number of transactions) and fixed costs associated with developing and maintaining the software in-house are avoided.

* Supply of labor – If there is a shortage of skilled labor, renting may be a more attractive option.

Small and medium sized businesses may derive value from renting applications by avoiding the need for in-house IT departments. Big organizations with complex business processes may prefer in-house development or buying components rather than renting to cater to their IT requirements.