May
2003 Issue: 28
May
2003 Issue: 28
Journal of Conceptual Modeling
www.inconcept.com/jcm
by Amjad Bashir
In this report, adoption of Component-Based Development (CBD) is viewed from a management perspective. Assuming that we engage in an in-house software development of a business organization, are to make a decision towards the adoption of the Component technology by looking at its benefits and risks.
Components promise a wide range of benefits in rapid development of quality software and cutting the timeframe down and conforming to budget constraints. On the other hand, there are some risks involved in terms of early adoption and available support at present. Ignoring it would just not be wise, as the benefits expected to appear are significant in terms of software reusability, reliability, functionality, and quality.
We will make some certain assumption about the in-house development of Component systems. We assume that we will develop Components providing services of all categories: user, business, and data services. But more emphasis will be on providing generic services, the middle layer containing business classes and implementing business systems. We might use COTS (commercial off-the-shelf) products for the best benefits of the organization (this involves risks as well and we’ll discuss them later on).
By adopting Component technology, we could benefit ourselves significantly as being an organization. The description of a few benefits is as follows:
Software quality is seen as “fitness for the purpose” and “fitness of the form”. Mainly, it’s only the first argument that matters “fitness for the purpose”, which means, system must DO what it’s supposed to DO. As Components come with very detailed description of its services. So, it will be helpful to improve quality of software by having clear description of what it does (i.e. fitness for the purpose).
· Functionality, Reliability, Maintainability, Reusability…
Components are usually designed to have very good design characteristics from software quality perspectives. So, Components are generally low coupled and high cohesive. Low coupling increases the reliability (because their dependency on other Components is minimal) and high cohesion augments their functionality (because the Component is focused). The modular structure of a Component-Based solution allows individual Components to be replaced easily providing easy maintenance. They are easily portable, as the specification of a Component is generally platform-independent.
· Less Down-Time
Organizations cannot afford to stop their daily operations for long periods whilst they test out new IT-Solutions for their businesses. Components may help offering competitive advantage by delivering flexible, better and faster solutions in parallel.
· Adoption of Legacy Systems
Still a large number of old systems exist in many organizations. Sometimes they don’t seem to be doing enough for them. Huge amount of dollars had been spent on them. In most cases, total replacement of such systems and building them from scratch is just not feasible mainly due to the amount of effort, time, and cost spent on them. Components are capable to adopt the legacy systems gradually and seamlessly. They may be added to such systems in an incremental fashion to increase their efficiency and functionality.
· Support For Evolving and Continually Changing Systems
We might need to develop dynamic systems for business organizations in future. Such systems have relatively higher potential for continual changes. For such evolving systems in an organization, more Components with additional functionality can be added. Similarly, for continually changing systems, embedded systems (E-Systems for example), Components may be modified as needed.
· Less Training
Component is seen as black box. One concerns only about the services it provides. For this reasons it has very well defined points of interaction (interfaces) realized by the Components. Thus, we will need less training for the users as compared to other technologies. This will reduce the time and the cost of training for the organization.
There is question should we adopt this evolving technology now or wait till it becomes bit clearer that what shape is this technology is going to take in future and then make a decision about its adoption?
Early adopters of this technology are already reaping the rewards of competitive advantage and additional revenue generation from selling their own Components. Currently the software Component market is estimated to be exceeding $670 millions and according to the latest research it will increase exponentially in coming years.
As we are not vendors and do in-house development only, we will not lose benefit in terms of selling our Components but, perhaps, be missing on other advantages discussed earlier.
If we are ever to adopt the technology on later stages, whether because of its market trend, demand or whatever, we will be avoiding those risks and difficulties that are obvious in the earlier adoption of IT-technologies or anything new when they are in evolution. We will then, as late adopters, choose a relatively mature technology and posses more knowledge and experience about them.
We don’t have a certain conclusion as we have to wait and see how this is going to be. But by looking at these factors, we could be the late adopters of the technology and this seems to have it’s own advantages as well as disadvantages.
Some benefits may be realized soon after the adoption of the technology. The early benefits expected to appear include rapid development within estimated budget constraints, less training costs, increased users productivity.
Some benefits may appear in the long run. We may expect to see reduced maintainability costs, reuse of Components for other projects, increased reliability and reduced ongoing support costs.
CBD reduces training cost & time, as it is relatively simpler technology to use. There would be no needs of setting up extensive training sessions for users in the organization. In large organizations, training is a critical cost factor costing them fortune. The benefit of reduced training cost will appear as soon as the technology is introduced.
It is a very critical issue in Software Development. Maintainability costs are often much higher than the original system development costs (Pressman, 1997). If we have systems entirely composed of Components with well defined interfaces and description of their services, it will be much easier for us to figure out what Components are the primary candidates for modification or even total replacement with respect to maintainability requirements.
Maintainability of Component-Based systems is also very critical and depends on the nature of the maintenance. Maintainability of fine-grained Components such as GUI controls will be easier than the Components implementing business services. Costs might be the same for the maintenance if we are dealing with the Component containing subsystems, entire legacy application and/or Component implementing the business rules. Components are easier to modify because of their simple design and low interdependence.
Adopting the technology will definitely cost something and it should justify itself. It is widely assumed that the Component-Based software development approach will be significantly less costly (i.e., shorter development cycles and lower development costs) than that of traditional methods of developing systems from scratch. A cost-justifying usability program may be helpful calculate the estimated cost and expected benefits of adopting the technology.
If integrating COTS (commercial off-the-shelf), an additional concern relating system development and maintenance may have to be negotiated to keep track their licenses to ensure uninterrupted operations of such systems. For example, a license expiring Component in the middle of a mission might have disastrous consequences.
We may have to employ new people. We might even have to bear training expense for some of the existing staff. Additional equipment and CASE tools may be needed for the development and maintenance. We may be spending to maintain a Component library for the storage such Components. We may expect costs for record keeping of documentation and manuals about them. We might have to spend in terms of setting up new environment and/ or change the existing.
If we look around to see available support for the CBD, we may find mainly three major technologies contributing towards implementing Component-Based solutions. Java Beans, COM+ and CORBA are the major technologies around at present. Java Beans seem to be doing very good for the web application and alike. One must take Microsoft’s .NET technologies into account as well. Others may also be effective and promising towards Component-Based implementation but still choice is very critical and context sensitive with respect to system requirements and depends heavily upon the future market trends.
“Components are set to become the next big thing in the software industry”. There is one thing that the entire software industry agrees upon and that is the case of adopting Component-Based Development (CBD) for implementing enterprise software solutions.
Bearing in mind the usual cross-section of differences amongst software vendors, the trade presses and the marketplace there must be a compelling reason for this consensus. So it would not be wise to ignore it completely or entirely overlook it.
Processes of developing systems normally have phases of writing requirements, analysis, design, coding, testing and installation etc. Development process for CBD differs from traditional processes significantly. Let’s see at a glance that what the process is, so that we can see what is different from typical and what seems to be changed?
In CBD, the notion of building a system by writing code has been replaced with building a system by assembling and integrating existing software.
CBD (Component-Based Development) involves not only building systems by putting Component together or making some modifications to existing Component but also the development of new Components.
Four major activities characterize the Component-Based Development approach; these have been adapted from Brown [Sterling Software 1998]:
· Component qualification (sometimes referred to as suitability testing)
· Component adaptation
· Assembling Components into systems
· System evolution
Component qualification is a process of determining "fitness for use" of previously developed Components that are being applied in a new system context. Component adoption is about that Components must be adapted based on rules that ensure conflicts among Components are minimized. Assembling means Components must be integrated through some well-defined infrastructure and System evolution, in a broad sense, will mean integration of Components.
But in contrast to traditional development process, where system integration is often done at the end, Components integration is the main idea of the development process. So, implementation is much more focused on the integration. Integration is also a key consideration in the decision whether to acquire, reuse existing or build new Components.
For CBD we have to see the requirement of the system as usual. But we will have a different perspective (integration, reuse etc) for writing them, for example, we write requirements from an OO perspective (class & object) if system is intended to develop using OO methodologies. Design phase will also be much more emphasized on integration. We might not have to write code at all. But if we do, because extra functionality is required or available Components are not capable to provide required functionality, we’d have to make some modifications to existing Component or develop new ones, which could lead us to a different “Development Process”. This development process may have its own development phases such as requirement, design and so on. Thus we can have nested development processes within systems using CBD for their development.
For testing phase we have to do different kinds of testing. As the system will be composed of different Components, we have to test them individually that they work. Then we have to perform integration testing by putting them together to see everything is working fine. Putting all of them together could cause problems. If we do that and we find some faulty functions, then it will be harder to figure out what Components are candidates for modifications. At the end the system will be tested as whole to see whether it works properly.
Staffing could be one of the major risks. We might have to downsize or upsize the organization, depending on the nature of existing capabilities of the employees to conform to new technology requirements. We might have to get rid of those who will not be able to cope with new changes and employ new to keep up with the requirement of this new technology. Also, we might have to train existing employees who have the potential to keep them up with new environment.
There are always risks involved to be an early adapter of something new. For example, buying first version of a computer application. There are often many things to be changed, enhanced, or improve in earlier versions. First version comes out, you buy it, use it and by the time you get use to of it. Vendor Company brings out the second version of the same product. You find a few or lots of feature of the application have been changed or totally replaced for its improvement. And you are, now, facing problems in using them or even don’t know how some of them actually work.
Same is the case with Component technology. Maturity of CBD is another major risk. It is still in its evolutionary stages, despite the fact it is a fast evolution. But still it does not seem to have a discrete shape as yet. If the integration using third-party Components (assuming that we might use commercial off-the-shelf Components sometimes) do not posses good design qualities and has not been appropriately tested, this may cause system failures in future.
One of the other major risks is that if we adopt Component technology at early stage and rest of community (organizations and individuals) doesn’t, we would be left alone and may suffer the loss. As Economics of Technology Standard (Adoption of Software Engineering Process Innovations; Fichman & Kemerer) has revealed that benefits from adoption of a software process innovation heavily depends on the size of potential future adopter.
Availability of CASE tools and other complementary products are another risk for a new technology. It would be difficult to get the desired results, in terms of time, cost and quality for a new technology if it does not have necessary complementary tools support and techniques developed at the time of innovation. Otherwise, we may have to put more efforts to achieve desired results. And that estimation of effort could cost a lot in terms of time, budget and some other critical factors.
What Are the Chances of Success?
According to the DOI (Diffusion of Innovations) & ETS (Economics of Technology Standard) perspectives (Adoption of Software Engineering Process Innovations; Fichman & Kemerer) CBD conforms to the most of requirements of successful adaptability.
ETS has revealed that benefits from adoption of a software process innovation heavily depend on the size of (past, present and future) community of adopters. We don’t have past adopters of the technology as such. But more and more organizations are adopting it presently. Particularly, vendors companies are making fortune from selling their Components. So, we could see that the potential for future adoptions among the community of other adopter.
CBD also seem to conform to DOI perspective as well. We could look at the characteristics of the technology, which could possibly make it successful. For example, we can see why the telephones are so successful? What are the characteristics of telephone, which made this so successful? World Wide Web is another example. CBD is promising to provide the characteristics like the quick development of quality software on time and budget, reuse and lots of others that had been challenging for IT industry.
Success of a software technology has also been significantly affected by the fact that what affects it have got on the software quality. According to ISO-9126, software quality has been characterized by six properties; functionality, maintainability, usability, efficiency, reliability and portability. Components seem very promising towards all of them.
Availability of staff and complementary technology are crucial for the success of CBD. It’s not a wholly solely new concept. Components inherit much of the characteristics from objects in the OO paradigm. People with OO background would not face lots of problems to familiarize themselves with the technology, though training may be necessary. CASE tools and other complementary products for OO may be used for the Components as well (but still more may be required).
Success of adopting a software innovation has been significantly affected by the factors; prior Technology drag, irreversibility of investment, sponsorship and expectation (Fichman & Kemerer). Lets see how Components seem to conform to them.
Prior technology drag does exist in the form of Object-oriented technology and CASE tools. Prior to that structured analysis was a drag for OO technology. Object technologies have been around successfully for quite sometimes now. They’ll be very helpful in boosting Component-Based applications.
Component software is very suitable for Web applications. Component applications are usually small, less dependent and strongly internally glued. Having these properties and being small in size they take minimum storage space and can be transferred quickly and easily over the network. There is no need to buy any additional software to use them. People would like to use them more because of their simplicity, less complexity and ease to use. And that’s how more and more market will be generated via WWW.
In terms of sponsorship, relatively few organizations have started practicing CBD seriously. A number of large software vendors have made a major commitment to Component-Based Development, including Forte, IBM, Microsoft, SAP, Sterling and Sun.
There is a possibility that CBD, despite having all the favorable features, may not become the future technology; we are going to suffer the loss in that case.
Component-Based systems encompass both commercial off-the-shelf (COTS) products and Components acquired through other means. If the CBD does not become big technology in future, the maintainability cost of Component systems could be huge. Because Components are sold as black boxes and we don’t have means to see inside them and if vendors of those Components no longer exist. Also, we would not be able to get new Components for the developments of new projects.
We may also have employed staff and invested on training. We will have to pay their wages, reorganize their responsibilities or downsize the organization. We may hire new staff according to the situation.
We may also have invested on buying other complementary products and CASE tools. They will be no longer of any use if CBD fails to dominate as future technology. That’s “bit” of loss as well.
Whilst doing Component-Based Development, we will mostly be doing integration of Components. We might be using commercial off-the-shelf (COTS) products sometimes. Either we want minimum development time or it’s just not feasible to develop certain Components. Original developer of such Components may be unaware of the uses to which their Components may have been put in. Moreover, if they are not adequately tested, we may find out conflict among different Components on later stages because they may have remained undetectable during early testing sessions. These issues may become visible on later stages when the end-user is extensively using the system. For large systems, this might have brutal effects for the organizations.
There are so many positive arguments (discussed earlier) in the favor of CBD that it only seems appropriate that we should go ahead and adopt the technology and benefit us from it. But before we get to any conclusion let’s brew some general issues, which enable us to think positively about the adoption of Component-Based Development Technology.
Finally, Why Do We Need Components? What Are the Problems?
As stated earlier, in the past, major software projects have not been able to meet the business requirements by using existing approaches. Time and budget have always been the most critical factors in the development and delivery of the systems. Systems have been implemented with timescales stretching to years. Modifications in an existing system required a lot of time to implement and re-deploy them & still there was, often, a question that whether desired level of functionality has been achieved?
Businesses are now relying on IT more than ever for acquiring information and making decisions on the basis of that information. They require rapid speed of change in Information Technology to meet their needs. This is putting immense amount of pressure on IS-departments to develop solutions in timeframes reduced to weeks rather than months or years.
Existing approaches (procedural and object-oriented etc) are not sufficient and have not done much to reduce the gap between IT and business needs. We are looking for something that fulfills today’s business ever-changing needs. And Components (CBD) seems to provide the solution.
Though, it’s not certain by adopting the technology the current problems will disappear over night. A lot have to be done and a lot have to be experienced to get to the final say. Very little, but very encouraging results of Components have shown that they are capable to resolve critical problems that have been terrifying IT industry such as rapid development, quality software, maintainability, cost, reuse etc.
The pros and cons on early and late adoption of CBD have been discussed in early paragraphs. Though it’s not certain whether early or late adoption will benefit us more, but in both cases advantages are likely to be there.
I personally think that we should go ahead and be the EARLY ADOPTERS of CBD. We will be well established and have more experience with the technology by the time it becomes big. We will be enjoying rapid developments and quick modifications of the systems built from Components. Or else we might still be putting huge efforts and dollar into maintaining conventional systems whilst others may be reaping the Components benefits. Maintainability costs are often much higher than the original development. Building application by putting Components together rather than developing from scratch through coding is really something that is needed NOW. The impact of software reuse, if fully realized, would have a significant effect on the software industry by slashing cost, improving quality and reducing time taken to develop applications.
Though this report does not cover the CBD from vendors’ perspective, but we cannot overlook their success using this technology. Enterprise businesses and software houses are NOW getting their Components evaluated by thousands of other businesses across the globe. And if we are ever to become vendors, we can turn our organization into more profit making organization by introducing a new source of revenue by selling Components.
1. The Unified Modeling Language, User Guide, by Grady Booch, James Rumbaugh, Ivar Jacobson, Addison-Wesley 1998.
2. Component-Based software engineering, by Thomas Jell, Cambridge University Press; (June 1998).
3. Software Engineering, A Practitioner’s Approach, Fourth Edition, Roger. S. Pressman, McGraw-Hill, 1997.
4. A paper on “Modeling Component Systems with the Unified Modeling Language”, Philippe Kruchten 1999, Rational Software Corp.
5. Adoption of Software Engineering Process Innovations; Fichman & Kemerer, Sloan Management Review/ Winter 1993
6. A paper on “A Practical Framework for Applying UML”, Paul Allen, SELECT software tools.
7.
Modeling Component Systems with
the Unified Modeling Language, Philippe Kruchten, Rational Software tools.
http://www.sei.cmu.edu/cbs/icse98/papers/p1.html
8. Brown, A. (1998), ‘Unified Modeling Language (UML)’, Sterling Software, http://www.cool.sterling.com/cbdedge1/techwatch.htm
9.
Home page of
Component Source, A Component Vendor Company
http://www.Componentsource.com/home/AboutComponents.asp
Amjad Bashir, Chairman Department of Computer Scineces & I.T.
Contact Information:
Amjad
Bashir
Chairman Dept.
of Comp. Sc. & IT, Old Campus, University of AJK,
Muzaffarabad 13100. Pakistan.
nashanaas@hotmail.com
© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement. ISSN: 1533-3825