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.).
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
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.
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.
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.
Value for systems integrators
Systems integrators add value by assembling components into systems and provisioning the application.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Implementation strategy - Big-bang or phased approach
Implementation of a new system may be done in one stage or as a phased process. In either scenario it may be decided to maintain the current (possibly manual) system running alongside for a period of time. The approach to be adopted would depend on the type of system, its mission criticality and the risk and costs of the failure of the new system. Each approach has its advantages and disadvantages:
Big Bang approach
This approach limits the duration of disruption in change over. However the lack of testing in real conditions can result in major problems. A well known example of this was the new London Stock Exchange system which had been incorrectly sized for the scale of dealing operations required of it. So, when at the start of computerized share dealing, every user logged on, and the system ground to a halt. This is an example where insufficient technical testing of the future system took place. However it is equally important to understand the user demand that will be placed on a system when it goes live and is introduced in a single phase.
Phased approach
With a phased approach, the manual system remains in place and is gradually phased out. Users can rely on the use of parts of the old system while gaining familiarity with the new system. This also allows the installers to take control of the new system, from time to time, to sort out problems as they arise. However, the running of two systems in parallel can cause extra confusion and the duration of disruption is extended.
A key requirement for successful phased installation is to ensure a smooth change over from the existing operation to the new system. A number of steps can be taken to achieve this:
- If functions are to be phased, they should be grouped into meaningful learning units which reinforce their operational integrity for the user.
- Clear procedures must be established to manage the manual/computer interface during installation. Extra resources must be provided to avoid backlogs and deterioration in working efficiency.
- In a phased implementation, the early phases of implementation should concentrate on those sections of the organization who will receive immediate benefits from using the system.
- Extra resources must be available to support end-users during take-on, training and early operation of the system.
- A clear plan to handle the delivery and accommodation of the hardware to minimize disruption to the workplace (e.g. workplace and workstation layout, cable installation and management).
The following table compares the two approaches.
References
- Industrial and Economic Properties of Software - Technology, Processes, and Value -David G. Messerschmitt Department of Electrical Engineering and Computer Sciences University of California Berkeley, California, USA
- Software Creation Industry- Software Ecosystems – MIT Press
- Modularity in the Design of Complex Engineering Systems - Carliss Y. Baldwin, Kim B. Clark January, 2004
- From Subroutines to Subsystems: Component-Based Software Development -Paul C. Clements
- Software Engineering Institute, Carnegie Mellon University
- Marketplace Issues in Software Planning and Design - David G. Messerschmitt, University of California, Berkeley Clemens Szyperski, Microsoft Research
- The Structure and Value of Modularity in Software Design - Kevin J. Sullivan William G. Griswold Yuanfang Cai, Ben Hallen
- The limits of software – Grady Booch – IBM Software Group
- System analysis and design – Alan Dennis and Barbara Haley Wixom
-
Developer Works articles -
- Overview of Modular Product Development CHUN-CHE HUANG Laboratory of Intelligent Systems and Information Management Department of Information Management National Chi-Nan University Puli, Taiwan, R.O.C.
- http://www.tcs.com/0_whitepapers/htdocs/engineering/towards_more_manageable_customized_servers.pdf
