The Bombardier Aerospace Strategy for the Deployment of New Technology
Tim Ambridge, Director, Processes & Tools, New Commercial Airplane Program, Bombardier Aerospace

Bombardier Aerospace exists to manufacture, sell and service aircraft. We are focused on providing an amazing experience to our customers in the process of meeting their needs. Bombardier Aerospace is not in the business of developing software; we do not make money developing or selling software. For Bombardier Aerospace, software is an enabler that allows us to make better airplanes, faster and at a competitive cost.

Bombardier Aerospace is one of the major components of Bombardier Inc., the other being Bombardier Transport, which is a world leader in rail transportation solutions. For the fiscal year ending January 31, 2005, Bombardier Inc. employed 61,070 people, 52% in Transport and 44% in Aerospace, and had revenues of US$15.8 billion (CAD$20.5 billion), 48% from Transport and 50% from Aerospace. Bombardier Inc. has a worldwide manufacturing presence, with facilities in 22 countries. The major Bombardier Aerospace facilities are located in Montreal, Quebec, Toronto, Ontario, Wichita, Kansas, and Belfast, Northern Ireland.

Bombardier Aerospace (BA) is the world's third largest aircraft manufacturer. We provide a complete line of aircraft: business jets, with nine models from entry level Learjets to the high end Global Express; six models of regional aircraft, both jet and turboprop; and the odd Amphibious multi-role aircraft! Our customer base is extremely varied and all bring different levels of expectations. In 2004 BA delivered 329 aircraft, 200 regional aircraft (178 jets and 22 turboprops), 128 business jets, and one amphibious aircraft. This is more aircraft than either Boeing (Commercial), with 285, or Airbus, with 320, delivered.

BA has developed and deployed fifteen new aircraft models in the last fifteen years, a record that rivals anyone in the industry. As a result of this rapid pace of aircraft development we may have had three or more models in development at any time. BA grew through acquisition, starting with Canadair, located in Montreal, in 1986. In 1989 we added Shorts Brothers PLC of Belfast, Northern Ireland, the first company to obtain a contract to build airplanes, from the Wright Brothers no less! In 1990 Learjet in Wichita, Kansas was added and in 1992 DeHavilland Canada, located in Toronto, completed the core of BA. It was by leveraging the existing skill sets and resources in place at each site and encouraging an entrepreneurial mind set that we were able to develop fifteen new models in fifteen years. There was however a down side to this rapid growth. Each site had its own existing set of products and supporting technology. Each site, each program grew independently and developed their own tools and ways of working. The rapid pace of aircraft development made it impossible to establish an integrated IS/IT environment; we essentially remained four different companies. One of our first cross-site initiatives was the development of CATIA V4 and CDMA on a distributed platform in 1992, when BA first developed the design in context concept with DS. At the same time Boeing was using massive mainframes and batch clash detection on the B777. By 2004 the BA product line had matured with fifteen models in production.

The economic downturn of 2001, coupled with increased competition and the need to prepare for a totally new product line, forced us to re-examine our technology position. Faced with these new business realities, we realized we had to rationalize and modernize our technology base, that we needed to replace the entrepreneurial model that had served us so well before. It was decided that the time had come to review the company's complete technology architecture and develop a strategy for future growth.

We started by clearly defining the principles on which we wanted to base our system. The following guiding principles were established:

• Privilege functional integration over best of breed applications
  It's better to have systems that talk to each other than the best piece of software



• Enable systematic decommissioning of applications
  New systems must replace obsolete systems, don't just add another layer to the onion



• Reusability of all target components
  Maximize the uses of the system, meet multiple needs with one application



• Data centric approach focusing on the identification of Master Data
  Data must be at the center of the selection



• Data should be integrated and updated from one source application
  Enter once, use often



• Enabling cross-functional processes and business strategies
  Structure systems and data to minimize re-purposing



• Demonstrate the Value Proposition throughout the Architecture
  Everything in the architecture must contribute to the overall value



• Ensure overall alignment with Technology Target Architecture
  Applications must not only meet functional requirements, their place in the system must be clear



• Harmonize with corporate direction
  The architecture must be directed towards meeting our business goals

Once the guiding principles were in place, the general system requirements were defined:

• Support of federated architecture



• Adequate response time in all situations



• Flexible reporting capabilities



• Single secure system access



• APIs independent of software revision



• APIs at the appropriate level of granularity



• Minimal reconfiguration when upgrading



• Data migration tools for software revisions and legacy systems



• Logical unit of work - reliable data management



• Availability of data exchange tools



• Availability of documentation



• End user, installation, implementation guide, technical, interface specifications, system upgrades



• Software openness for integration to other systems, Robustness of application and functions

We then implemented a standard methodology for developing the conceptual architecture, starting with the business vision and objectives and taking into consideration the principles and guidelines as well as the existing situation. This allowed us to identify the functional components, the necessary common services and, most importantly, the data flow that would allow us to fully integrate the components. The physical architecture was then derived from the conceptual architecture by comparing the potential applications with the different use scenarios and, when necessary, performing fit-gap analysis. The resulting functional requirements framework allowed us to link the applications to business processes and identify the required automation. One of the major challenges in this is to clearly understand and communicate the conceptual architecture, select the potential applications and obtain a detailed knowledge of those applications.

BA put together a set of selection criteria to aid in choosing from among the various applications available. While some measure of subjectivity will always (and should) be involved, we have tried to quantify the selection criteria as much as possible. The selection criteria used by BA are:

• Functional Fit



• How well does the system meet the identified requirements



• Vendor assessment



• Market position, customer base



• Past record on delivery, ease of upgrade, support



• Availability of existing best practices and methods



• Architecture fit



• How well does the system fit with other existing or targeted systems



• Minimum customization, ease of configuration



• Deployability



• How easily and quickly can the system be deployed to the user base



• Ownership Costs



• Acquisition Costs



• Customization, Development & Upgrade Costs



• Deployment Costs



• Data Migration



• Integration



• Training



• Human Change Management



• Operating & Support Costs



• System Maintenance - Admin, 1st level support



• Application Services - 2nd & 3rd level support



• Managed Services - including disk space and servers



• Management Overhead



• Software maintenance costs

Business processes and the underlying enabling technology are entangled at a basic level; one inevitably and intrinsically affects the other. Standard techniques of gathering requirements frequently leads to an automated "as-is' process. Most users will only identify incremental or evolutionary improvements ("give me a new field; I need to be able to print this; etc.") to the technology while ignoring opportunities to actually improve the business process. This often results in a system that is less efficient and less flexible. Rather than gather requirements about what the application should do, we focus on the desired end result by following the data and continually asking why it is needed. Working back from the desired results makes it easier to identify improvements and streamline the process. Processes done in isolation from the enabling technology will inevitably result in massive customization, user disappointment or both. We realized that in the end our people are far more adaptable and flexible than software. Business and IS/IT visionaries must combine to provide the technology and processes required to move the organization to the next level.

Some of the basic lessons we have learned at BA regarding the introduction of new technology are:

• Do the greatest good for the greatest number.



• Concentrate on the 20% of the functionality that will provide 80% of the benefits because 80% of the users will only use 20% of the functionality.



• Use pilot projects to prove the 20% of the functionality that will be used by 80% of the users, as well as the best-known and most important exceptions. As much as possible, force software providers to do the quality audits of their products.



• It is better to deploy simpler functionality to a large number of users, than complex functionality to a small number of users.



• The business case should ensure that the costs are justified; it should not be aimed at generating a specific ROI within an artificially fixed time period. New technology almost always generates unintended benefits that could not be foreseen; give people the freedom to make the decisions necessary to keep the company in a leadership position.



• Establish the system architecture based on data flow and high level processes.



• Begin the "human" change process early and ensure that these activities are well supported and protected when the need to make cuts arrives.



• Establish training programs early, and ensure that business priorities can support the training program, and train cross-functionally whenever possible, this will help drive out some of those "unintended benefits" early.



• Expect resistance, understand that not everyone will be able to adapt and make the transition.