Building business sustainability: why Agile needs Lean Startup principles?

In his book on leadership titled On Becoming a Leader, Warren Bennis wrote: "Managers do things right while leaders do the right thing". This quote can help explain why Agile needs Lean Startup principles.

Toward Product Leadership

Lean Startup is about Product Leadership. In business, the ultimate goal of the enterprise is to eventually generate revenue and profit and that requires having enough customers who are willing to pay for a product or service. This is the key to sustainability in a free market system. The concept of the Lean Startup was first introduced by Eric Ries in his book titled: The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Steve Blank wrote an article in the Harvard Business Review last year titled: Why the Lean Start-Up Changes Everything.

Agile is about the management of Product Development. When applied properly using techniques such as Test Automation and Continuous Delivery, Agile (and its various flavors like XP, Scrum, or Kanban) is a proven methodology for successful software delivery. However, a purely ceremonial approach (daily standup, sprint planning, review, retrospective, story pointing, etc.) may not yield best results.

Having the best software developers in town and building a well-designed and well-tested software on time and under budget will not necessarily translate into market success and business growth and sustainability. So what is the missing piece? How do we ensure that Agile is delivering a product that users are willing to buy? How do we know that the software itself and the many features that we work hard to implement every sprint are actually going to be needed, paid for, and used by our customers?

How Agile projects can become big failed experiments

Agile promotes the use of cross-functional teams that include business users, subject matter experts (SMEs), software developers, and testers. There is also the role of Product Owner in Agile teams. The Product Owner and the business users help the team define and prioritize backlog items. The issue is that most of the time, neither the Product Owner nor the business users are the people who are actually going to sign a check or use their credit card to buy the product. This is the case when the product will be marketed and sold to the market at large. Implementing the wrong design and building the wrong product can be very costly to the enterprise. So the result is that the design and the features that are being implemented by the development team are just assumptions and hypotheses (by so called experienced experts and product visionaries) that have never been validated. Not surprisingly, many Agile projects have become big failed experiments.

Untested assumptions and hypotheses

What we call vision and strategy are often just untested assumptions and hypotheses. Yet, we invest significant time and resources pursuing those ideas. A deep understanding (acquired through lengthy industry experience) of the business, customers' pain points, regulatory environment, and the competitive landscape will not always produce the correct assumptions about a product. This is because the pace of change has accelerated dramatically over the last two decades.

Traditional management processes and tools like strategic planning and the Balanced Scorecard do not always provide a framework for validating those assumptions. Even newer management techniques like the Blue Ocean Strategy taught by business schools to MBA candidates contain significant elements of risk and uncertainty when confronted with the brutal reality of the marketplace.

This reminds me of my days in aviation training. Aviation operations are characterized by a high level of planning. The Flight Plan contains details about the departure time, route, estimated time enroute, fuel onboard, cruising altitude, airspeed, destination, alternate airports, etc. However, pilots are also trained to respond effectively to uncertainty. Examples of these critical decision points are the well known "Go/No Go" decision during takeoff and the "Go-Around" during the final approach to landing. According to the Flight Safety Foundation, a lack of go-arounds is the number one risk factor in approach and landing accidents and the number one cause of "runway excursions".

The following is how the FAA Airplane Flying Handbook describes the go-around:

The assumption that an aborted landing is invariably the consequence of a poor approach, which in turn is due to insufficient experience or skill, is a fallacy. The go-around is not strictly an emergency procedure. It is a normal maneuver that may at times be used in an emergency situation. Like any other normal maneuver, the go-around must be practiced and perfected.

 

Applying Lean Startup engineering Principles

A software development culture that tolerates risk-taking and failure as a source of rapid learning and growth is actually a good thing. The question is how do we perform fail-safe experiments early and often to validate our assumptions and hypotheses about customers' pain points and the business model (how money is made), quickly learn from those experiments, and pivot to new ideas and new experiments until we get the product right? The traditional retrospective in Agile usually involves discussion about what went wrong and how we can improve with a focus on the activities performed by team members. The concept of pivot in Lean Startup engineering is different. The pivot is about being responsive to customer feedback and demands in order to build a sustainable and resilient product and business. The pivot has significant implications on the architecture, design, and development of a product. As Peter Senge wrote in his book titled The Fifth Discipline: The Art and Practice of the The Learning Organization:

The only sustainable competitive advantage is an organization's ability to learn faster than the competition.

The Lean Startup recipe is to create Minimum Viable Products (MVPs) that are tested early and often with future customers of the product. An MVP can be created through rapid prototyping or by incrementally delivering new product features through Continuous Delivery, while leveraging cloud-based capabilities such as a Platform as a Service (PaaS) to remain lean. Testing MVPs requires the team (including software developers) to get out of their cubicles or workstations and meet with customers face-to-face whenever possible to obtain direct feedback and validation. MVPs can also be tested through analytics, A/B testing, or end-user usability testing. Actionable metrics like the System Usability Scale (SUS) should be collected during these fail-safe experiments and subsequently analyzed.

These fail-safe experiments allows the Product Owner and team to refine the product vision and business model through validated learning. Lean Startup principles are not just for startups. They can also make a big difference in established enterprises where resource constraints combined with market competition and uncertainty can render the traditional strategic planning exercise completely useless.

How Checklists Can Enhance Clinical Decision Support (CDS)

I have been reading "The Checklist Manifesto", a book written by Dr. Atul Gawande on the effectiveness of checklists in healthcare delivery. Another paper recently published in the Milbank Quarterly entitled "Counterheroism, Common Knowledge, and Ergonomics: Concepts from Aviation That Could Improve Patient Safety" suggests that beyond checklists, proven aviation safety practices such as Cockpit Resource Management (CRM), Joint safety briefings, and first-names-only rules could help improve patient safety.

I first became aware of the importance of checklists while I was being trained as a Flight Engineer. I spent a lot of time studying them carefully as an aviation student. Checklists are used during normal, abnormal, and emergency situations and pilots go through practical exercises in flight simulators to use them correctly. Let's not mince words: aviation as we know it today would not be possible without checklists.

In a study entitled "Missed and Delayed Diagnoses in the Emergency Department: A Study of Closed Malpractice Claims From 4 Liability Insurers", researchers found that:

The leading breakdowns in the diagnostic process were failure to order an appropriate diagnostic test (58% of errors), failure to perform an adequate medical history or physical examination (42%), incorrect interpretation of a diagnostic test (37%), and failure to order an appropriate consultation (33%). The leading contributing factors to the missed diagnoses were cognitive factors (96%), patient-related factors (34%), lack of appropriate supervision (30%), inadequate handoffs (24%), and excessive workload (23%).

Checklists can serve as cognitive aid in helping clinicians do their job safely. While the idea of using checklists and standard operating procedures has been fully embraced and adopted by aviation professionals for more than 70 years, it is only now making inroads into the field of medicine particularly in high pressure environments like intensive care units. The use of checklists in medicine has already shown the potential to save patients live and reduce human errors. However, the main challenge remains the acceptance of checklists by clinicians concerned about "Cookbook Medicine".

Checklists are just cognitive aids and the presence of an experienced and competent professional will always make a big difference in critical situations. As Captain Sullenberger (the airline pilot who successfully ditched US Airways Flight 1549 in the Hudson River in New York City, on January 15, 2009) said, "One way of looking at this might be that for 42 years, I've been making small, regular deposits in this bank of experience: education and training. And on January 15 the balance was sufficient so that I could make a very large withdrawal."

On modern airplanes, Electronic Centralised Aircraft Monitor (ECAM) systems or Engine Indicating and Crew Alerting Systems (EICAS) monitor aircraft systems and engines and displays messages in case of failure, as well as recommended remedial actions in the form of checklists. The National Transportation Safety Board (NTSB) accident report on US Airways Flight 1549 indicates that the First Officer "was able to promptly locate the [Engine Dual Failure checklist] procedure listed on the back cover of the [Quick Reference Handbook] QRH, turn to the appropriate page, and start executing the checklist."

In medicine, factors such as comorbidity can complicate the design of effective CDS. However, with the explosion of medical knowledge and evidence-based guidelines, CDS will become an essential tool in healthcare delivery. The design, development, implementation, and use of CDS is knowledge-intensive and require an effective collaborative knowledge management strategy. The challenge will be to integrate checklists into the different CDS modalities such as context-sensitive Infobuttons, order sets, alerts, reminders, data entry and visualization, and clinical workflows.

For example, the evaluation results (in the form of recommendations) of a CDS rule can be presented to the clinician as an electronic checklist. This in turn can be tied directly to quality measures in the era of Meaningful Use, Pay-For-Performance, and Accountable Care Organizations (ACOs). An interesting example would be a checklist that prompts clinicians to generate detailed discharge instructions to satisfy quality measures for patients with heart failure or acute myocardial infection.

There is an important Human Factors aspect to the design and use of cockpit checklists and flight-deck procedures. This has been the subject of advanced research at NASA Ames Research Center more than twenty years ago and the results have been widely disseminated and implemented in the aviation industry.

In an article entitled "The Checklist" published in the New Yorker, Atul Gawande wrote:

"But consider: there are hundreds, perhaps thousands, of things doctors do that are at least as dangerous and prone to human failure as putting central lines into I.C.U. patients. It’s true of cardiac care, stroke treatment, H.I.V. treatment, and surgery of all kinds. It’s also true of diagnosis, whether one is trying to identify cancer or infection or a heart attack. All have steps that are worth putting on a checklist and testing in routine care. The question—still unanswered—is whether medical culture will embrace the opportunity."

Peter Pronovost, an intensivist at Johns Hopkins Hospital and pioneer in the use of checklist in medicine, implemented a checklist at 127 Michigan intensive care units (ICUs) to reduce catheter-related blood stream infections (CRBSI). The project was so successful that it is estimated that it could significantly reduce the 28,000 deaths and 3 billion dollars in costs caused by these hospital-acquired infections.

The HL7 Clinical Decision Support (CDS) workgroup is working on standards for the vMR (Virtual Medical Record), Infobuttons, and Order Sets. There is also an effort at the OMG to publish a Clinical Decision Support Services specification for service-oriented CDS capabilities. The Flight Operation Interests Group (FOIG) of the Air Transport Association (ATA) is developing a data model and XML Schema for flight deck procedures and checklists. Developing a shareable content model for checklists in medicine could be an interesting idea.

Content Integration in the Aviation Industry Using CMIS

The recently approved Content Management Interoperability Services (CMIS) specification could play a very important role in ensuring that aircraft operators receive up-to-date maintenance and operation documentation from aviation manufacturers.

The safe and efficient maintenance and operation of air vehicles require clear, technically accurate, and up-to-date technical documentation. The technical documentation is supplied by original equipment manufacturers (OEMs), regulatory agencies, and the aircraft operator's own engineering staff. OEMs (e.g. airframe, engine, and component manufacturers) provide regular publications such as Aircraft Maintenance Manuals (AMM) and Flight Crew Operating Manuals (FCOM) as well as time-sensitive supplements such as Service Bulletins (SBs) and Temporary Revisions (TRs). Regulatory agencies like Transport Canada and the US Federal Aviation Administration (FAA) also publish technical information that affects the maintenance and operation of air vehicles and equipments. Examples are Advisory Circulars (ACs), Airworthiness Directives (ADs), and various forms and regulations.

A typical airline faces the following challenges:

• The elimination of the high costs associated with the shipping, storage, and distribution of physical products (paper, CDs, and DVDs) containing the technical documentation.
  
  
• The safety and regulatory compliance concerns related to the use of out-of-date technical information (currently, some airlines receive revisions to technical manuals only four times a year).
  

The aerospace industry is in the process of adopting the new S1000D technical publications standard. S1000D is based on the concepts of modularity, reuse, and metadata (see my post on S1000D Content Reuse). The Flight Operation Interests Group (FOIG) of the Air Transport Association (ATA) is developing a data model and XML Schema for flight deck procedures and checklists also based on the S1000D data model. While S1000D is the right payload format, the exchange between content management and publishing systems within the industry must be orchestrated in an efficient manner.

Airlines, repair stations, regulatory agencies, and original equipment manufacturers (OEMs) manage and publish technical content using proprietary content management systems (CMS) each with its own proprietary API. Some companies now provide online portals where customers can login to get the latest documentation. However, pilots and technicians don't really want to login into the support sites of all those content providers to find out what is new and updated. To minimize aircraft downtime, aircraft mechanics want to connect to the aircraft's health and usage monitoring system (HUMS), determine what problem needs to be fixed, and have the appropriate content aggregated (work package) and presented to them.

With CMIS, an airline or aircraft operator can create a portal to aggregate content from the repositories of its OEM suppliers using a single standardized web services interface based on either SOAP or AtomPub (the RESTful alternative). This allows the aircraft operator to keep their maintenance and operation documentation updated at all time without having to wait for a CD or paper manual to be shipped by the OEM.

The second scenario is distributed authoring driven by the shift to distributed aircraft manufacturing. For example, the content of the Aircraft Maintenance Manual (AMM) can be provided by different aviation manufacturers participating in a consortium to design, manufacture, and support a new aircraft. In such as a scenario, a centralized CMIS-compliant content repository (hosted by the airframe manufacturer acting as the content integrator) can provide the following CMIS services to other members of the consortium:

• Policy and ACL Services to obtain the policies (such as retention) and Access Control List (ACL) currently applied to a document
  
  
• Navigation Services to programmatically navigate the content repository
  
  
• Discovery services to query content. CMIS supports SQL-92 with some extensions and full-text search and can handle federated search across multiple repositories
  
  
• Relationship Services to obtain the relationships (such as links) associated with a document
  
  
• Versioning Services to check-out and check-in a document
  
  
• Object Services to obtain the properties of a document and create folders and documents
  
  
• Filing Services to add a document to a folder.
  

The third example use case is the ability for a SCORM-compliant Learning Management System to integrate with CMIS-compliant S1000D Common Source DataBases (CSDB) in order to repurpose technical publications content for training purposes. The International S1000D-SCORM Bridge Project is an interesting initiative to create such an integration.

In general, CMIS will enable new capabilities such as the remote access to library services, cross-repository exchange, cross-repository aggregation, and cross-repository observation (or notification).

CMIS is now supported by major CMS vendors including EMC, IBM, Alfresco, and Microsoft. A list of open source and commercial implementations of CMIS is available at this page.

Green EHRs, Genomics, Decision Support, and Checklists

I am back in the blogosphere after a three month hiatus. As you may have noticed from my last post, my focus lately has been on health information technology and how to unleash its potential to improve the quality of care and reduce costs. Healthcare Reform has been signed into law in the US as I have predicted in my last post. I believe that the healthcare sector is going through what former Intel CEO Andy Grove calls a "Strategic Inflection Point" driven by a combination of the following:

• A new regulatory framework including Healthcare Reform, ARRA and the HITECH Act
  
• Technology: electronic health records, advances in Genomics, and leveraging the ubiquity and ease of use of Web 2.0/3.0 platforms
  
• Innovations in the practice of healthcare delivery such as personalized medicine, automated execution of clinical guidelines (evidence-based medicine and clinical decision support), and the growing awareness of the effectiveness of checklists in high-pressure clinical settings such as surgery and intensive care.
  

Developing robust and easy to use health IT standards is key, so I've joined the HL7 standard development organization to follow and hopefully contribute. Specifically, I am interested in the following HL7 working groups:

The HL7 Structured Document Working Group and the Greening of the CDA

This group develops structured document standards for healthcare such as the Clinical Document Architecture (CDA) and the Continuity of Care Document (CCD). I am particularly interested in the greenCDA effort to simplify the CDA. I believe that simplifying the CDA can greatly facilitate and accelerate adoption. A simpler version of the CDA will allow adopters to quickly learn it and use their familiar software development tools (such as XML databinding tools and IDEs) to write software applications. To achieve that objective, data components of the greenCDA will be based on data semantics as opposed to the CDA R-MIM (Refined Message Information Model) classes. The CDA R-MIM is a graphical representation of the CDA specification and a step in the HL7 V3 Reference Information Model (RIM) refinement process.

HITSP C32 took the right approach by first defining required data elements for various content modules such as conditions and medications and then mapping those data elements to the HL7 CCD XML Schema structure. However the latter is quite complex. Fortunately, it is possible to map those HITSP C32 data elements to a simpler XML Schema than what is defined by the HL7 CCD. That simpler XML Schema can take different forms. A National Information Exchange Model (NIEM) Information Exchange Package Documentation (IEPD) for healthcare data is an approach that is being considered by the ONC. The NIEM approach is proven and has been successfully used in complex data exchange scenarios in criminal justice and other sensitive domains. Another approach is to create a lighter version of the HITSP C32 specification like the L32 proposed by the MITRE corporation.

There are many new interesting features of the XML Schema 1.1 specification such as assertions and conditional type assignments that can be leveraged as well to consolidate both structural and business rules data constraints in a single schema.

While there are different approaches to simplifying the CDA, instances of any well-designed simplified version of the CDA/CCD should easily be mapped to the original plain vanilla CDA/CCD schemas for exchange.


The Clinical Decision Support Working Group

This group develops standards such as the Virtual Medical Record (vMR), GELLO (an expression and query language for computer-interpretable clinical guidelines), Infobutton (a context-aware information retrieval standard specification), and Clinical Decision Support Services (CDSS).

Clinical Decision Support systems had a limited adoption but are likely to get a boost from the new ARRA EHR certification requirements.

The Clinical Genomics Data Working Group

This group develops standards for clinical and personalized genomic data such as DNA sequence variations and gene expression levels. Combined with clinical decision support services, this work has the potential to revolutionize personalized medicine as we know it. For example, a medication dose can be adjusted based on a patient's genotype. Family history and genetic screening will play an important role in preventive medicine for diseases such as diabetes and cancer.

Procedures and Checklists in the Cockpit and Intensive Care Units

The Flight Operation Interests Group (FOIG) of the Air Transport Association (ATA) of which I am a member is developing a data model and XML Schema for flight deck procedures and checklists. Adherence to well designed flight deck procedures and checklists can contribute significantly to the improvement of flight safety. For example, several no-flap/no-slat takeoff crashes have been caused by a deviation from basic operating procedures.

Aircraft manufacturers have different philosophies and policies on the design of flight deck procedures that must be reconciled. Another challenge is the need to take human factors into consideration in any effort related to the design and execution of flight deck procedures.

While the idea of using checklists and standard operating procedures has been fully embraced and adopted by aviation professionals for the last 70 years, it is only now making inroads into the field of medicine particularly in intensive care units. The use of checklists in medicine has already shown the potential to save patients live and reduce human errors. However, the main challenge remains acceptance and full embrace of checklists by clinicians. If you are interested in learning more about checklists in medicine, I recommend the book "The Checklist Manifesto: How to Get Things Right" by Atul Gawande.

A checklist could take the form of a tasks list automatically generated as output of clinical decision support services that take as inputs electronic health records as well as patient genomic data for a more effective form of personalized medicine.

S1000D and SCORM Integration

This is a presentation I gave at the DocTrain Boston 07 conference on how to reduce product lifecycle costs by integrating the S1000D and SCORM specifications.

S1000D is the International Specification for Technical Publications utilizing a Common Source Database (CSDB). Based on open XML standards, the latest issue (4.0) has been developed by the AeroSpace and Defence Industries Association of Europe (ASD), the Aerospace Industries Association of America (AIA), and the Air Transport Association of America (ATA).

Sharable Content Object Reference Model (SCORM) is a specification for online learning content developed by the Advanced Distributed Learning (ADL) Initiative.

The presentation has been updated to reflect the addition of SCORM support in S1000D 4.0.

S1000D and SCORM Integration

View more OpenOffice presentations from Joel Amoussou.

AtomPub Use Cases in the Aviation Industry

At the XML 2007 Conference in Boston, I introduced my concept of an Integrated Documentation Environment for Aircraft Support (IDEAS) based on AtomPub and OpenSearch. The following are some use cases that illustrate how such an approach could facilitate integration and technical information publishing in the aviation industry:

• Notification. Nancy is an aircraft mechanic. When she gets to work in the morning, she opens her feeds aggregator to get new and updated content from all of the following sources: airframer, engine manufacturer, component manufacturers, FAA, or airline policies. Essentially, Nancy doesn't want to login into the support sites of all those content providers to find out what is new and updated. She wants content pushed to her instead. This use case is implemented with the Atom syndication format.


• Federated search. While Nancy is repairing the hydraulic tank, she wants to perform a single search against all those content repositories. She wants the results aggregated and returned to her as Atom entries, so that she can subscribe to those items that she is interested in and receive updates via web feeds. This use case is implemented with the OpenSearch specification.


• Airline Originated Changes. Judy is an engineer working on a new engineering order (EO) to be performed on the hydraulic tank. The airline's technical documents are hosted by the aircraft manufacturer. Judy uses an XML editor which is also an AtomPub client to post the EO to the remote content repository (an AtomPub server).


• Distributed Aircraft Manufacturing. Future Composites Inc. is a supplier of composite aircraft structures to X-Aero, a major airframer (systems integrator). Future Composites is also responsible for providing technical content in S1000D to X-Aero on those composite structures. After a failed attempt to connect to X-Aero's repository using their SOAP and WS-* interface, Future Composites and X-Aero mutually agree to go back to the basics and use AtomPub and its simple and generic RESTfull HTTP interface to CRUD (create, retrieve, update, and delete) documents to X-Aero's content repository.

The main argument in favor of this approach is simplicity and scalability. I am glad to see that the software industry is moving in that direction. Having been involved in complex WS-*-based integration projects in the airline industry, I believe this new approach is a breath of fresh air. The RESTful approach is also more amenable to agile software development as opposed to the waterfall approach which is typical when the big up front purchase of a proprietary ESB is involved.

Integration projects are becoming critical to the success of new aircraft projects. Speaking about the repeated postponement of the 787 maiden flight in an internal memo send to Boeing employees on April 21, 2008 (and obtained by the Seattle Times) Boeing CEO Jim McNerney wrote:

I expect we’ll modify our approach somewhat on future programs—possibly drawing the lines in different places with regard to what we ask our partners to do, but also sharpening our tools for overseeing overall supply chain activities.

Why AtomPub specifically? Because too many people have been putting the "REST" label on their unRESTful chef-d'oeuvre (HTTP APIs) lately. AtomPub is a good embodiment of the principles of the REST architectural style and a good place to start.

So, what are the key principles of RESTful design:

• Everything is a URI addressable resource
  
• Representations (media types such as XHTML, JSON, and Atom) describe resources and use links to describe the relationships between those resources.
  
• These links drive changes in application state (hence Representational State Transfer or REST).
  
• The only type that is significant for clients is the representation media type, not any other resource type
  
• URI templates (a la OpenSearch) as opposed to fixed or hard coded resource names
  
• Generic HTTP methods (no RPC-style overloaded POST)
  
• Stalessness (the server keeps no state information)
  
• Cacheability
  

Adherence to these principles is what drives massive scalability. Security in a RESTful application can be achieved with any of the following existing solutions:

• XML Signature and Encryption
  
• OpenID
  
• HTTP Authentication
  
• SSL
  

How does the aviation industry gets started with this new approach? This will require leadership from aviation IT specialists, particularly from original equipment manufacturers (OEMs). I don't think that another Air Transport Association (ATA) standard committee is needed. Such standard committees are plagued by vendor politics. By the time they finish their work, someone may have invented a better solution than AtomPub.

In the Java space, the recently approved Java API for RESTful Web Services (JAX-RS) specification greatly simplifies REST development with simple annotated POJOs. Jersey is the open source reference implementation of JAX-RS. Apache Abdera is an AtomPub implementation with Spring Framework integration. The latest release of Abdera features a collection of pre-bundled Atom Publishing Protocol adapters for JDBC, JCR, and filesystems.

The following is an excellent technical article from InfoQ that explains how REST and AtomPub facilitate integration: "How to Get a Cup of Coffee".

Boeing 787 Flight Control Software and Composite Fuselage Tested

Randy Tinseth, Boeing Commercial Airplanes vice-president for marketing announced on his blog that Boeing chief pilot Mike Carriker and 787 systems director Mike Sinnett successfully tested the flight-control Blockpoint 8 software code in the 787 engineering flight simulator. He wrote:

During the test, Mike and Mike demonstrated most of the operational procedures required by a flight crew - pushback and engine start at Sea-Tac airport near Seattle, taxi and takeoff, climb, cruise, simulated engine failure, descent, approach, single-engine go-around, landing, taxi and arrival at the gate at the Portland, Oregon airport.

Boeing also performed a serie of test on the composite fuselage of the B787 including "limit load", "ultimate load", and beyond 2.5 times the normal force of gravity (2.5 G). According to a Boeing press release dated 02/28/2008:

Testers observed audible indications of damage as the test progressed but the piece did not reach the level of destruction that had been anticipated.

This is a significant development because last September, Boeing announced the delay of the maiden flight of the first 787 due to flight control software issues, fastener shortage, and supply chain bottleneck. Also last year, a former Boeing engineer went public with concerns about the survivability of the 787 composite structure in case of a crash.

The maiden flight has been postponed again to June this year. First delivery to launch customer All Nippon Airways is scheduled for early 2009.

UPDATE: On April 9, 2008, Boeing has announced that 787 maiden flight has been postponed to the 4th quarter of 2008 and the first delivery for the 3rd quarter of 2009.

Speaking about the 787 globally distributed aircraft manufacturing model in an internal memo send to Boeing employees on April 21, 2008, (and obtained by the Seattle Times) Boeing CEO Jim McNerney noted:

I expect we’ll modify our approach somewhat on future programs—possibly drawing the lines in different places with regard to what we ask our partners to do, but also sharpening our tools for overseeing overall supply chain activities.

Aviation Data Management in the Web 2.0 Era

I will make a presentation at the XML 2007 Conference in Boston on December 5. The title of my presentation is: RESTful IDEAS. IDEAS stands for Integrated Documentation Environment for Aircraft Support. Based on AtomPub and OpenSearch, the IDEAS Framework enables federated searches of technical content and updates via web feeds. This presentation is essentially about how Web 2.0 innovations can be leveraged to create a cost-effective, efficient, and massively scalable environment for aggregating and publishing up-to-date technical documentation to end users in the aviation industry.

So what exactly is Web 2.0? Does it mean anything at all? For me Web 2.0 represents new web functionalities such as:

• Content aggregation and syndication using technologies like RSS and Atom
  
• Social networking (e.g. Linkedin and Facebook)
  
• User generated content with videos, pictures, blogs, wikis, and podcasts (e.g. YouTube and Flickr)
  
• Mashups or the ability to merge data from different sources (e.g. Google Maps and Yahoo Pipes)
  
• Rich Internet Applications (RIA) using user interface technologies such as Flex and AJAX
  
• Web Services and web-based APIs particularly those using RESTful protocols such as AtomPub
  

Those are the types of functionalities that today's web users expect from web applications, and the consumers of aviation technical documents are no exception.

Atom and AtomPub are already playing a fundamental role in the Web 2.0 world. The Google Data API which also includes Google Documents is based on AtomPub and OpenSearch. This week, a group of social networking sites including hi5, LinkedIn, MySpace, Ning, Orkut, and XING released OpenSocial which is a common set of APIs for developing social applications across multiple websites. OpenSocial is also based on AtomPub.

So how can the aviation industry embrace and extend Web 2.0 innovations to solve the challenge of aggregating and presenting up-to-date technical data from multiple content sources? I will be sharing my thoughts.

See you in Boston!

Guidance for the Paperless Cockpit

One of the interesting applications of the Electronic Flight Bag (EFB) is electronic documents. Electronic documents allow aircraft operators to amend manufacturer’s flight operations manuals based on operator's policies and procedures and publish these manuals in electronic formats such as Adobe® Portable Document Format (PDF) and XML. Examples of these manuals are:

• Flight Crew Operating Manual (FCOM)


• Quick Reference Handbook (QRH)


• Flight Crew Training Manual (FCTM)


• Minimum Equipment List (MEL)


• Fault Reporting Manuals (FRM)


• Weight and Balance Manual


• Dispatch Deviations Guide

US Federal Aviation Administration (FAA) Advisory Circular (AC) 120 76A “Guidelines for the Certification, Airworthiness, and Operational Approval of Electronic Flight Bag Computing Devices” specifies the design and technical criteria for the approval of the human/machine interface of EFB systems. The following is an excerpt of the EFB Operational Evaluation and Approval Job Aid used by FAA inspectors for electronic documents functionalities:

• Is there a training program on how to display and interact with electronic documents? Is it adequate?
  
• Can the crews find the material they are looking for?
  
• Is the information organized in a way that makes sense to the crews?
  
• Is the information arranged in a consistent way on the screen so that the crews know where to look for specific types of information?
  
• Is it obvious when text is out of view? Is it easy to bring that text into view?
  
• Can the crew tell where they are in relation to the full document?
  
• Can the crew tell where they are in relation to the section of the document they are currently viewing?
  
• Is the text of the document easy to read on the screen?
  
• Is white space used to separate short main sections of text?
  
• Is high priority information especially easy to read?
  
• Are tables readable and usable?
  
• How are especially long and complex tables handled?
  
• Are figures readable and usable?
  
• Can the entire figure be viewed at one time?
  
• Can the crew zoom in to read details on the figure?
  
• Is it easy to move quickly to specific locations (e.g., to the beginning of a section, or to recently visited locations)?
  
• Are active regions (e.g., hyperlinks) clearly indicated?
  
• Is it easy to move between documents quickly?
  
• Is it easy to tell what document is currently in view?
  
• Is there a list of available documents to choose from?
  
• Can crews search the document electronically?
  
• Is the search technique adequate?
  
• If animation is supported, does the crew have adequate control over it?
  
• Can the crew start and stop the animation as needed?
  
• Is there a text description of the animation that describes its contents (so the crews know its contents without running the segment)?
  
• Is printing supported? If so, is it adequate?
  
• Can crews select a portion of a document to be printed?
  
• Is the hard copy usable?
  
• Can the crew terminate a print job immediately, if necessary?
  

These criteria have been developed as the result of research into human factors in the use of electronic documents in EFBs by the Human Factors Division of the Office of Aviation Programs at the Volpe National Transportation Systems Center. Knowing these criteria in advance can help an aircraft operator in preparing for approval. However, I believe that operators can benefit from a more detailed set of specifications in regard to the interface to electronic documents. Section 6.3.1 of the S1000D standard provides rules and guidance for the look and feel, and printed output from an Interactive Electronic Technical Publication (IETP). Section 6.4.1 defines a functionality matrix for IETPs to be used as an aid for defining requirements for S1000D projects. The functionality matrix leverages the US Department of Defense (DoD) long experience in defining class 1 to 5 IETMs with military specifications MIL-PRF-87268 and MIL-PRF-87269. For example, in the area of searching, the S1000D functionality matrix provides very detailed guidelines that go beyond the simple criteria "Can crews search the document electronically?" and "Is the search technique adequate?". The matrix breaks down searching functionalities into:

• Full-text search
  
• User-defined Boolean search
  
• Search across multiple databases and files
  
• Context search
  
• Keyword search
  

Publishing EFB electronic documents in XML provides many benefits over the Adobe® PDF format. Key enabling technologies for XML-based EFB electronic documents are: ISO Schematron, XSLT, XSL FO, XLink, XPointer, XInclude, and XQuery. For quality assurance, the electronic documents application should be subjected to rigorous unit testing and functional testing before its release to flight crews. A content management system can help an operator by providing features such as workflow routing, versioning, document locking, access control, and full audit trail of modifications made to documents.

The Air Transport Association (ATA) has adopted S1000D as the next generation aircraft digital data standard and there is already a very close collaboration between the ATA and the S1000D TPSMG to harmonize commercial aviation technical data requirements with S1000D. That collaboration should be extended to electronic documents for EFBs to allow aircraft operators to leverage and influence the development of the S1000D IETP functionality matrix for better guidance on creating the paperless cockpit.

Canada welcomes the C-17

The Canadian Air Force will receive this weekend the first of four strategic lift aircraft-the C-17 Globemaster III.

This is a special occasion for the Canadian Air Force for the following reasons:

• The men and women of our armed forces who are deployed in dangerous peace keeping operations worldwide deserve the best equipment and logistics support we can afford, and they need them now.


• Canada needs its own airlift capability to provide quick humanitarian relief and piece keeping operations anywhere in the world when needed.

The C-17 was competing against the EADS A400M. The C-17 was a good choice for Canada because:

• The C-17 is a proven airlifter and Canada can leverage that experience immediately.


• EADS revealed last week that the A400M's first flight has been delayed until "the summer of 2008", and that "the consequence on deliveries and cost is under assessment".


• Finally, I must confess that I've always been in love with the C-17 for its design and record breaking capabilities.

My russian aviation adventures

Fifteen years ago, in the summer of 1992, I had the opportunity to fly the Tupolev 154 as a flight engineer. I was flying with an Aeroflot crew based in St-Petersburg, Russia. This was part of a flight training program that also included theoretical studies at the Russian Academy of Civil Aviation in Aviagorodok (near St-Petersburg) and practical exercises on a flight simulator.



The Tu-154 did not have a glass cockpit like modern aircrafts, so the flight crew had to be skilled in aerodynamics as well as aicraft systems and engines. For someone who wanted to learn about airplanes, this was the right airplane to fly. The Tu-154 was powered by three Kuznetsov NK-82 turbofans and was a very reliable airplane at the time. The Tu-154 seats about 160 passengers and flight crew of three or four. I was seated on the flight engineer deck. My role was to control and monitor the aircraft's engines and systems (hydraulic, electrical, pneumatic, air conditioning, and APU) during normal, abnormal, and emergency situations. Each flight started with a visual inspection of the exterior of the airplane followed by some systems and engines checks inside the cabin.

The Tu-154 flight manual was a good guide and I was fortunate to have a very professional and experienced instructor during the simulator training. The flights took me to the following cities:

• Anapa
• Mourmansk
• Dnepr
• Kiev
• Moscow
• Simferopol
• Volgograd
• Krasnadar
• Sotchi

All these flights were uneventful and gave me the chance to discover the russian countryside. It was a pleasure to fly with the rest of the crew. They were interested in learning few english and french words from me. My first 6 months in Russia were spent learning to speak, read, and write in the russian language. The total immersion helped learn the language very quickly and I was able to take all the aviation courses and read the aircraft technical documentation in russian.

I wanted to revive my memories of flying the Tu-154 with a PC-based flight simulator. While surfing the web, I found a web site for Project Tupolev Tu-154B2 which is a flight simulator for the Tu-154. In the simulator, the flight engineer panel is very detailed and realistic. It is divided in sub-panels for engine parameters, hydraulic system, electrical system, etc.

Instructions are provided on how to get the engines and systems started, but clearly, my previous knowledge about the aircraft was very helpful. The simulator comes with an english user guide, but the flight deck is completely in russian.

The simulator can be downloaded from the Project Tupolev Support Site.

RESTful IDEAS

About a year ago, I published a white paper entitled: "Beyond S1000D: an SOA Enabled Interoperability Framework for the Aerospace Industry".

The white paper proposed a framework called "Integrated Documentation Environment for Aircraft Support (IDEAS)" for the interoperability of enterprise content management and publishing systems within the aerospace industry. The goal was to allow new capabilities such as the remote access to library services, cross-repository exchange, cross-repository aggregation, and cross-repository observation.

Global aerospace organizations acquire technical publications from multiple suppliers and business partners. They must address the following challenges:

• The elimination of the high costs associated with paper libraries and the shipping of physical products such as paper, CDs, and DVDs.


• The safety and regulatory compliance concerns related to the slow distribution of supplements to field sites.


• The need for a single point of access to the multitude of technical documentation needed to maintain and operate aerospace equipments.

The IDEAS concept was created to address current inefficiencies in technical data management processes within the industry by taking advantage of Service-Oriented Architecture (SOA) and emerging content management standards such as the JSR 170 Content Repository for Java Technology API.

One the Java EE platform, JSR 170 is enjoying a lot of success in terms of adoption and implementation. In the Open Source world, the Apache Jackrabbit project continues to evolve and there is now a Spring JSR 170 Module to simplify development with the very popular Spring Framework.

For cross-platform interoperability, SOA based solutions have traditionally relied on web services standards such as SOAP, WSDL, and UDDI. However, in today's Web 2.0 world, alternative approaches such as the Representational State Transfer (REST) architectural style and the OpenSearch specification (for federated searches) are getting a lot of attention for their simplicity and scalability.

REST is based on the notion that resources on the web are URI-addressable and that all CRUD (Create, Retrieve, Update and Delete) operations on those resources can be implemented through a generic interface (e.g., HTTP GET, POST, PUT, DELETE). In contrast, RPC-based mechanisms such as SOAP use many custom methods and expose a single or few endpoint URIs. It turned out that the requirements for interoperable enterprise content management systems are more amenable to the REST architectural style.

The resurgence of REST can be felt across the application development landscape. Struts 2 introduced a REST-style improvement to action mapping called Restful2ActionMapper (itself inspired by the REST support in Ruby on Rails). Support for RESTful web applications is been added to JSF through the RestFaces project. REST APIs are also easy to implement with scripting languages such as JavaScript and FreeMarker.

The technical documentation needed to operate and maintain an airline's fleet is supplied by several manufacturers including aircraft, engine, and component manufacturers. Regulatory agencies ( FAA and the NTSB) also publish documents such as Advisory Circulars (ACs), Airworthiness Directives (ADs), and various forms and regulations. If all these organizations expose their content repositories via OpenSearch, then an airline technician will be able to perform a federated search across all those repositories to obtain technical information about particular equipment. The results could be formatted in ATOM to allow the technician to receive updates via web feed.

To expose a library service with a REST-style API, a content management system would typically need to provide the following:

1. A description of the service including URI templates, HTTP method binding, authentication, transaction, response content types, and response status


2. The specification of the code (script or Java ) that is executed on the invocation of the URI


3. Response templates

JSR 311, the Java API for RESTful Web Services will define a set of Java APIs for the development of Web services built according to the REST architectural style.