Choisir les standards plutôt que les pratiques propriétaires

Introduction

There are a number of standards, procedures, and processes that an organization can use. At the high level, there are two primary types of standards: procedural (how do we do it) versus technical (what do we follow). Organizations implement internal procedural standards so they are able to operate efficiently. They may also incorporate external procedural and/or technical standards. Technical standards have traditionally been pioneered through consortiums or standards bodies. The technical standards can be either public, standards-based or a proprietary de facto standard. The purpose of this document is to discuss and emphasize the importance of conforming to open technology standards that are external to the organization. Let’s begin the discussion, however, by looking inward to internal procedures, processes and standards.

Why should organizations have standard procedures at every level? Following standards is certainly not a new organizational phenomenon; organizations require their employees to follow common rules, or a common set of standards all the time. Memos, time cards, and accounting procedures are all standardized across groups.

In the development world, there is a need for standards because applications are designed across multiple development groups. Many organizations publish internal development standards and practices. For example, an organization may decide that C++, Java, and JavaScript will be the primary coding languages. They may require that each project be comprised of Marketing Requirements Documents, Product Requirements Documents, Functional Requirements Documents, Quality Assurance Test Plans, and Certification Documents.

As organizations mature, they discover that they need more processes to give them greater control, which allows them to more easily plan and predict. With processes, organizations can make release schedules, implement marketing plans, analyze resource allocations, and make adjustments when needed. Adherence to standards and processes can actually provide a level of flexibility because development does become predictable. In addition to predictability, standard processes improve understanding and streamline costs.

Un processus de développement commun

As an organization matures, managers and engineers develop a fundamental understanding of the importance of requiring adherence to these processes. When projects are proposed, they are evaluated to ensure compatibility with the overall business strategy. Product marketing must then analyze the marketability of the application/product, and then conduct in-depth technical evaluations and market research studies. If the project is accepted, the compiled information, analysis and research is merged into a Request for Proposal (RFP).

This process is not unique: most organizations have basic project management processes for product or service. Even within organizations, their processes are fine-tuned to work within the existing culture. When this happens, a development standard is created and is expected to be followed.

It is easy to get caught up in the process and forget why organizations have these processes in place. Bottom line, organizations have them because they save money, time, and resources. Sure, there are other reasons -– accountability, checkpoints, and scheduling, for example. The end result, however, is having a process in place that maximizes the organization's investment.

Autres standards

It is also important to follow other types of standards across an organization. There are numerous standards organizations that affect how and why we do what we do. For example, in the accounting arena there is FASB (Financial Accounting Standards Board) and IASB (International Accounting Standards Board). All businesses are expected and required to follow the guidelines set forth by the FASB. When auditors evaluate an organizations financial health, they do so by following the FASB rules.

Focusing on the software development portion of an organization, there are numerous standards bodies that can affect development decisions. For example, if an organization is developing a web-based client, they may have to adhere to standards imposed by these organizations:

• ANSI (American National Standards Institute),
• ATSC (Advanced Television Systems Committee),
• ECMA (European Computer Manufacturers Association: Standardizing Information and Communication Systems),
• IEEE (Institute of Electrical and Electronics Engineers),
• IETF (Internet Engineering Task Force),
• IRTF (Internet Research Task Force),
• ISO (International Standards Organization),
• ITU (International Telecommunication Union),
• OASIS (Organization for the Advancement of Structured Information Standards),
• OMA (Open Mobile Alliance (formally WAP)),
• UNI (Unicode Consortium), and
• W3C (World Wide Web Consortium),

Like the processes and standards that accountants and project managers must follow, the above-mentioned standards organizations provide focus and direction for the development engineering community. By following the guidelines that have been put into place, organizations like AOL can enhance user experience, interoperability, code reuse, shared resources, and goodwill while reducing costs. I will discuss each of these items in the following paragraphs.

The key to interoperability is settling on a standard that has a potential for long-term use. An organization must have the assurance that the standard they choose to incorporate into their development process will be relevant in the future. In other words, there must be long-term potential. A fundamental mistake that many organizations make is to use proprietary methods, software, code, or standards. Following a proprietary path has led many organizations down disastrous paths.

Case in point: Xerox Corporation. Xerox was clearly ahead of their time in the early 1980’s when they designed and developed the Star Office System. It was an elegant workstation with an iconic desktop developed by the engineers at PARC (Palo Alto Research Center). The Star Office System offered functionality that neither Microsoft nor Apple has been able to match with their current offerings.

The engineers developed Star on a proprietary development operating system known as Pilot. Pilot had a highly-integrated debugging tool called Co-pilot that allowed the Xerox development organization to quickly and easily debug issues. However, what Xerox neglected to understand was that regardless of how powerful Pilot and Co-pilot was, the Star Workstation could not evolve with the times because it was proprietary. Xerox was bound to a unique hardware platform and to a closed development operating system. And Xerox chose to bypass multiple opportunities to port the code to other platforms, and to provide open-source code. Consequently, Xerox eventually had to shut down the production of their workstation development because of escalating manufacturing and developing costs and slowed sales.

Xerox’s biggest asset in the beginning became its weapon of destruction. They settled on a proprietary environment, and missed the opportunity to make their environment the benchmark – and set the standard.

Following open standards has an added benefit. When it is necessary for an organization to interact with other applications through alliances, merger, or acquisition, the integration and interoperability is much less costly if all parties involved follow the standards from the outset. Consistent standards significantly reduce development re-work, and ensure consistent and predictable behavior from one application to the next.

Expérience utilisateur et bonne volonté

Customer retention and market expansion is critical. When customers choose to use a particular product, they must have a positive experience with consistent, reliable, and predictable behavior. As users become more sophisticated, and as additional devices become more affordable, they will be accessing the same information across a variety of devices – and expect them to look and act the same – regardless of whether they are accessing a web site from their desktop, phone, or handheld. Consequently, if an organization offers a suite of products they must ensure that the user experience is consistent and predictable across the product line.

Cohérence

To be successful, organizations need to understand this user expectation and provide a consistent experience across their product offerings. When usability alters too much across products, users complain.

Apple and Microsoft have learned this lesson well. When a Macintosh user shifted from Mac OS 8.x to Mac OS 9.x, the interface and desktop metaphor was virtually unchanged. Users could quickly and easily shift from one version to the next. However, when Mac OS X was released, Apple completely revamped the interface and desktop metaphor. That change caused quite a rumble through the Apple user community. It changed just enough to make it awkward, but not enough to where the user could not adjust. Apple received both good and bad press; and they lost some users and won some others over.

An example of how consistent user experience wins user loyalty can be seen in how Microsoft ensures common behavior across applications. For example, in Word, Excel, and other Windows applications, we know that pressing CTL+C within any Microsoft product means copy. The behavior is consistent and predictable and has subsequently become the de-facto standard. The reason it is consistent and predictable is because Microsoft has established a corporate set of usability standards and supports the relevant international standards.

Accessibilité

No organization can afford to overlook or ignore accessibility standards. Within the web environment, the accessibility standards are closely tied to HTML, XML, XHTML, and other W3C standards. By integrating and supporting the accessibility guidelines, an organization can offer their product lines or services to a larger and more diverse user base.

Interchangeabilité

If a user experiences consistent behavior across a range of products, they can predict how a particular action or function will work or respond. As a product provider, the goal should be the element of least surprise. By instilling a set of global goals and standards into an organizational infrastructure, an organization is ensuring its end users the ability to interact, function, view, and process information consistently as they transition from one device to the next.

A significant drawback in allowing divergence across applications is that information must be replicated, altered, or massaged to be processed across the divergent applications. This also creates issues in regard to authoring tools for these various applications. For example, let us say we have multiple application offerings that can be used to browse the web. Each of these applications has followed their own development and support standards. They each may support some or part of the international standards, but not fully. What authoring tool should we use? Would it be fiscally prudent to develop proprietary authoring tools for each application? What would the market adoption rate be for the suite of applications in this case? How can an organization consistently win market share if their product offerings are not integrated? More importantly, what if the user perception is that their products are not interchangeable?

Ressources Partagées

When an organization instills a corporate-wide policy of shared standards, they can leverage engineering resources across multiple projects. The development engineers can shift more readily between projects with little to no downtime. Coding practices are consistent. Expectations are known. There is equivalent functionality across applications offered by the organization. And, the engineers have a broader base of experience, making them more valuable within the organization.

For example, if web-based applications are expected to be W3C compliant, each engineer would be expected to know and understand the W3C standards. Development efforts would consequently support similar levels of standards support, which could possibly lead to cross-application coding, or code reuse.

For example, if a development engineer writes an application following the ANSI standard of C and C++, and writes that code on a particular platform, that code can be compiled on any other platform and operating system that supports ANSI standards. Microsoft products are difficult to export because they introduced MFC (Microsoft Foundation Classes), which is a Windows-only standard that does not follow the ANSI standard.

Assurance de la qualité

We know from experience that without rigorous testing, our products can fail miserably when we introduce them into the market. Technical support is costly not only in regard to support staff costs, but also in respect to customer dissatisfaction.

That is why organizations also need to apply standards to quality testing. By adopting a set of standards, the QA organization can produce a set of test suites that they can use across multiple projects. By having a standardized set of test suites, the QA organization can easily maintain, verify, and certify the tests, and eliminate redundant testing databases to ensure consistency and reliability. Like the engineers, standardization also helps the QA engineers become highly proficient and capable of shifting from project to project.

Résumé

As organizations expand product development across multiple devices and product families, integration and compatibility must be a key requirement. Adhering to a set of future-focused International standards will make cross-functional integration possible. Adopting standards will not only help an organizations end users enjoy a cross application experience; organizations will help themselves by giving development and quality assurance engineers the tools to become better equipped and flexible. Lastly, by following a series of standards, organizations can more easily measure progress, performance, and results across the organization.

The most compelling dilemma is how an organization chooses to follow open external standards versus a proprietary de facto standard. Following proprietary de facto standards leaves an organization vulnerable and open to obsolescence when the owner of the de facto changes focus or direction, or abandons the de facto altogether and renders the standard stagnate. On the other hand, by adopting open technology standards and participating in the development and direction of those standards, an organization is providing a path for future development, growth and revenue.