Was looking through my old archives and I found this old essay I wrote. My favorite quote is: “No technology, methodology or product has produced any radical improvement in productivity for over 20 years and it unlikely any thing will be developed soon…” I really should have substantiated it a bit better!
Written By Rory Ford 12th April 2000) Republished 4th November 2011
Life’s tough as a software architect. While your striving for a well-engineered system, everybody else wants the software delivered now or preferably yesterday. Wouldn’t it be great if you could rapidly deliver a well engineered system at little or no extra cost.
Well stop dreaming. No technology, methodology or product has produced any radical improvement in productivity for over 20 years and it unlikely any thing will be developed soon (if ever). However there are numerous strategies you can utilise within the software architecture that can help both the quality of the product and its delivery schedule. One of these is the utilisation of a component-based architecture.
Component based architectures provide a framework to support the assembly of a collection of existing software units (components) so as to provide the functionality required by the system or application. By relying on existing components we have less software to develop and hence can build it faster. [Meyer97] Component development lets us focus on capturing business logic rather than solving esoteric technical issues.
In a sense, component development represents the industrialization of the software development engineering process based on the assembly of common, tested elements. Component development assumes there are enough common elements in large software systems to justify developing reusable components that can be easily implemented in many applications. [INFO667] It is our goal as a software architect to utilise components to perform these common tasks.
When looking at components, most developers think of relatively small components, such as ActiveX controls or JavaBeans. However, from an architectural perspective, medium-sized business components that encapsulate proprietary business rules such as customer credit, discounts, and cash investment strategies are much more important. Even more important is the large grained application framework that provides the software infrastructure that all components use in executing an application
The reuse of these medium sized business components within the component framework is a key factor in using components for rapid development. They are usually mapped to associated business objects. For an example of this refer to the Purolater case study. As components are used more and more, it should become possible to purchase ready-made components containing generic business logic.
The framework used is important too. It can either be purchased off the shelf or developed from scratch (see Federal Aviation Administration). However the best architectures built from scratch are based on industry standards. In this case CORBA is the basis for the FAA. As the component software field grows, we should hopefully see convergence on a single standard.
Purolator Case Study
Sourced from [INFO613]
Purolator, in Mississauga, Ontario, is Canada’s largest courier service, with 10,000 employees moving 1 million packages daily. The company is also Canada’s third-largest airline, with 47 planes flying cargo worldwide. A vital element of Purolator’s business is time. The company’s core activities-pick-ups, deliveries, scheduling, and routing-all depend on efficiently managing the clock and responding quickly to the changing needs of customers.
Time was also Purolator’s enemy. The company’s mainframe-based systems were poised to collapse on Jan. 1, 2000. “We were wondering how to approach this, because we had to do a significant reengineering of just about everything,” said Philippe Richard, chief IT architect at Purolater.”The project was so big, we couldn’t see how it could possibly be managed in the time we had left.”
Also, some customers wanted Purolator to provide value-added services, such as a virtual warehouse, that required changes to the shipping company’s applications. Traditional development techniques could solve Purolator’s year 2000 problem, but they weren’t flexible enough to keep pace with the shipper’s changing requirements. Also, they were too slow. Purolator risked losing business to competitors if it took too long to deploy changes requested by customers. “With traditional development, we couldn’t deal with change,” Richard says. “Taking 12 months to build something three customers asked for didn’t make much sense.”
Purolator decided to move to client-server and a component-based architecture, which the company calls a services-based architecture because Richard’s team built distinct building blocks-“black boxes”-that precisely reflect Purolator’s business processes. To build these, the team used component-modeling tools from Rational Software, paired with Microsoft’s Visual C++ and Component Object Model (COM)
Each of Purolator’s business objects represents a contract between the company’s IS group and business units. Also, the business objects deliver functionality in a way that can be clearly understood and defined by both programmers and business managers.
Also, Purolator’s system is ready for the next millennium in more ways than one. Something as trivial as a date calculation will never again require a complete overhaul of the 10,000-user information architecture. Rather, the date component can be replaced, leaving other components that use its services unaffected by the change.
As new, unexpected, and inevitable changes to Purolator’s business model arrive, the company’s flexible component-based architecture promises the ability to rapidly adapt. “We now receive requests for pick-ups in four or five ways-phone, fax, E-mail, the Internet-and who knows what’s next,” says Richard. “If I have to change the way the system processes requests every time we add a new service, we’d be out of business. With components, I just snap the new service in.”
Federal Aviation Administration (FAA) case study
Source: OMG web site
The Federal Aviation Administration (FAA) needed to deploy an application very quickly to support their new telecommunication network. They developed a reusable server-side business component framework which was the basic foundation for their application and its associated services. This general framework could also be reused for other applications outside the scope of the project. It was the first step in the development of enterprise level horizontal frameworks.
Rapid development was a substantial need. By using components and a common framework architecture, the FAA can develop new applications rapidly. FDAA report a 90-day turnaround from start to finish on developing new applications based on their framework. The FAA estimates that this framework will save 60-80% of the resources needed to develop future applications.
Allied signal Case Study
Source: [CORBA1]
Allied Signal’s Engine Division spent two years building reusable objects based on CORBA application programming interfaces and set up CORBA to serve as the plumbing that connects components, clients, and servers. The framework is completed, and the first application built on it was completed in 1997.
“We’re building the fundamental building blocks that developers will use as they build applications in the future,” said Wayne Haughey, information systems group leader at AlliedSignal’s Engine’s Division. “Every time we pick this up and build a new application, we’re avoiding [about] five man-years of work – and that’s very conservative.”
At Object World West ’97 in San Francisco, Haughey said that the five man-years account for a savings of $750,000 per new application. CORBA enables applications, components, and databases to communicate easily with one another across multiple operating systems..
Discussion
Here are three success stories of using component frameworks in various ways. However there are also failure stories. Its just that are much harder to find (hence no failure case study. Like any architectural decision, the use of a component based architecture should be thoroughly researched.
However, there is no doubting that component architctures have shown a noticeable reduction in development times for their first use and even better reductions in subsequent projects based on the same architecture. The Purolater case study also demonstrates that component based architectures can also help to manage one of the banes of rapid development – changing requirements.
However it is important to recognize that the use of a component based architecture is not enough to guarantee rapid development. Other practises will be required across the project to keep the amount of work to a minimum. However components are on way that you the architect can help structure the system or application to be deployed sooner and to allow for extension and modifications in the future.
References/Bibliography
[CORBA1]
Case Study of Allied Signals
http://www.corba.org/aerodef/allied.html
[Info677]
Information week
April 13, 1998, Issue: 677
[INFO613]
Information week
January 13, 1997, Issue: 613
[MEYER97]
Object oriented software engineering
Second edition
Bertrand Meyer
Rapid Devlopment: Taming wild software schedules
Steve McConnell
Published by Microsoft Press 1996
Rory Ford 