Jacquard (pronounced like "jack-card" with more emphasis on the second syllable) is a software development methodology specialized for Web projects, and especially suited for such development among diverse teams.

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.

In 30 seconds

If you are developing a project for a Web site or Web applications, you need an agile methodology, but you also need a backbone of disciplined communication to tie together the entire team, which includes sponsors of the projects, Web designers and user experience specialists, application developers, database administrators, and more. You need a strong architect at the center of the project who understands the Web, is experienced at communication and collaboration, and experienced in aligning technology with business needs. Jacquard is a methodology that offers tools and techniques to guide you through all these concerns.

Jacquard is organized around a handful of core principles, and carefully describes how these principles intersect the various roles in a Web project. One practical aspect of Jacquard is the community effort to analyze technologies to determine how well aligned they are with Jacquard principles, or to suggest the most effective usage patterns.

Outline of the core principles:

1. Enable decentralized communication
2. Separate project concerns without losing cohesion
3. Progress through frequent iterations
4. Maintain independence from implementations
5. Use rich storyboards to drive the development
6. Design the URL space carefully
7. Keep architectural decisions close to the project
8. Plan for measurements

Why Jacquard

The Web is important enough, and in many ways is unique enough as an information system to deserve its own methodology for development. Unlike traditional enterprise applications, which are designed to be tightly specified at first, and unfortunately often unravel under real-world pressures, the Web is sloppy by design, and designed to endure constant change and even abuse. This means the "big design up front" philosophy is often a specious approach for Web projects (but mind you, if you are designing plane avionics, and you don't use BDUF, you're begging to need an army of lawyers).

Many established agile methodologies such as XP and Scrum focus on the wrong problems with heavyweight methodologies for Web development, and though often misunderstood by their critics, are often implemented in ways that omit some of the most important documentation, and impede communication.

Resources

• "Jacquard: a methodology for Web publishing" - Introductory article

• mailing list

Overview of Jacquard

Jacquard (pronounced as a near-rhyme with "Picard" of Star Trek fame) emphasizes communication and collaboration between possibly distributed sub-teams. Different roles and functional groups are directed to express their interests in as clear and yet natural a manner as possible. Jacquard supports using the Web as much as developing for the Web. It doesn't bless any specific toolkit and implementations and is rather a set of guiding principles against which such tools can be evaluated. Jacquard tries to avoid reinventing terminology and seeming too "cultish". Jacquard principles are not meant to seem magical.

Participants in Jacquard include:

Domain experts

Line-of-business managers and executives

Project and operational managers

responsible for tracking progress and coordinating sub-teams

User Experience

Web designers, Web QA etc. ( http://en.wikipedia.org/wiki/User_experience_design )

Application developers

programmers, database analysts, etc.

Architect

The most responsible party for Jacquard process. Responsible for ensuring the documentation and work products are suitable for cross-functional direction and communication, and analyzing progress against requirements

A Jacquard architect can come from one of many overlapping areas such as Information architecture, Data Architecture or Enterprise Data Architecture. The main additional qualification is that the Jacquard architect must be an expert at Web architecture.

In smaller projects several of the above roles might be taken up by the same person or team. In a large project there should always be a dedicated architect.

One way to organize participants in a Jacquard project is in the forms of information model they are concerned with. Domain experts, project and operational managers are mostly concerned with the conceptual models. User experience is mostly concerned with conceptual and logical models. The Application developers are mostly concerned with the logical and physical models. The architect is responsible for maintaining the coherence and value of all of these.

Jacquard principles

Enable decentralized communication

Contrary to some methodologies which work best when all participants are co-located Jacquard is designed to support teams spread out over the continents. With the increase of off-shore outsourcing and flexible work arrangements, distributed teams are the growing reality, and Jacquard encourages should decentralization and rich communication.

This is one area where Jacquard differs from many agile development processes. Jacquard acknowledges that there are too often geographical, cultural and practical impediments to pair programming, frequent face-to-face stand-up meetings and the like. It encourages the use of collaboration technology as much as possible, but never as a substitute for writing things down. Jacquard requires formal and informal supporting documentation to make it clear how the business domain is translated to logical and then physical models. It doesn't go as far as some traditional methodologies, however, in requiring so much design material upfront that it distorts the project and creates a burden for maintaining the material in the face of inevitable changes. The goal of Jacquard documentation is not imperative detail to guide every corner of the project, but rather broad conceptual alignment. This is why the core concepts definition is so important in Jacquard.

Once there is enough documentation to establish conceptual alignment, operational running of the project can be enhanced through the use of Web-friendly collaboration systems such as Wikis, archived mailing lists and distributed version control systems.

Web analogue. The Web works well across geographical boundaries.

Separate project concerns without losing cohesion

It's important to addressing the different needs for various roles in a Web project without tangling the work products so that they are hard to understand and to maintain. A well-known principle in document-oriented systems such as the Web is to separate content from presentation. The corresponding Jacquard principle is similar, but more general. The team should carefully separate concerns in the work product, but should make it easy to connect between the intermediate work products. The concepts definition is the ideal means for making this connection.

To give a concrete example, Web designers might come up with wireframes that include the markup structure of the final page and stylesheets which specify the presentation. Markup element classes and IDs are the usual means for matching the structure to the presentation, and it's important to use terms and business rules from the concepts definition to specify these classes and IDs. This is an example within one role of supporting separation of concerns while maintaining conceptual connections.

The Web designers might also develop forms to gather information from users, while the application and database group develops the modules to handle this user input. They should use the conceptual definition to connect the form fields to the database or application data structures.

Progress through frequent iterations

It's well established in agile development processes that iterations reduce risk and improve alignment with business goals.

Jacquard encourages the typical agile process guideline of one week to one month per iteration, each of which is a microcosm of the software development lifecycle.

Maintain independence from implementations

Techniques for specification and communication should respect as much as possible the diversity of tools people prefer to use, as long as they are all Web-friendly. Programmers who prefer to never leave emacs might find it distasteful to receive Web wireframes created by the UX team in Dreamweaver, but the core methodology should make no discrimination.

Web analogue. The Web has proven itself as the best integration platform ever put into practice. One Web site might be running an all-Microsoft stack on an Intel Xeon box producing HTML mixed with Silverlight components, while another might be a Sun server running J2EE with Java applets on the client, while a third might be a generic AMD kit with Debian Linux serving up standards-compliant XHTML with SVG. Regardless of the very different characteristics of the back-end applications these all work together seamlessly.

Use rich storyboards to drive the development

Storyboards are a classic component of UX design. Jacquard encourages storyboards that engage the imaginations of the team while supporting clear expression of the business domain (i.e. conceptual alignment). Web site projects often benefit from respect for personality of the users, which underscores the value of some especially creative approaches to storyboarding, such as http://designcomics.org/ . Regardless of whether the storyboards go that far, it's important for them to help clarify the business domain, and to highlight potential artefacts and conflicts of viewpoint.

See also:

• "An introduction to user journeys"

Design the URL space carefully

URLs should be designed so that they are stable and reliable, so they can be guessed and "hacked". Good URLs help organize the Web application's features for maximum effect. URL design should be a subject for storyboards, and communicated clearly to all participants. Ideally URLs should be designed around the most abstract and fundamental aspects of the implemented services. They should not include any implementation details.

See also:

• "Cool URIs don't change" - Tim Berners-Lee

Keep architectural decisions close to the project

Architectural decisions should be made with the specific needs of the project in mind. Architectural standardization across an enterprise, e.g. by a senior enterprise architect or architectural control board, is good discipline, but can sometimes be too rigid. One of the core characteristics of Web systems is that if are well designed they can be readily integrate, which reduces much of the need for heavily centralized architecture. Tools and techniques evolve rapidly on the Web, and

Plan for measurements

"If it moves, measure it". Your user stories are but a guess. Jacquard gives you the agility to rapidly Web projects adapt projects, and the best way to take advantage of this is to put metrics in place so that you can determine patterns that suggest changes to the product. These metrics might be in place during a alpha or beta phase to ensure a more effective full launch, but it doesn't end there. Good metrics are the best way to forsee strategic changes later in the lifecycle.

Many agile methodologies urge you to prepare for testing form the very beginning of the project. In addition, Jacquard encourages you to prepare for metrics from the beginning. In addition to obvious metrics such as access volumes, referrers, user entry and exit points, determine what measurements make specific sense for the project at hand, and make sure process and facilities are in place to set baselines maintain reports, and to analyze results.

Analyses

Analyses are discussions and examinations of various technologies to see whether they are suitable for Jacquard projects, and usage patterns and techniques that are particularly effective in Jacquard projects.

Distributed version control systems (DVCS)

DVCS is a very useful approach to managing work products in a Jacquard project. DVCS is designed for distributed teams, and it supports a variety of conventions for sharing work. For example each sub-team might have its own "stable" repository into which changes are pulled from individual repositories. These can then be merged into a shared, stable repository in order to complete each iteration of the project.

See also

• "Intro to Distributed Version Control (Illustrated)"

• http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how1.pdf

UML

work in progress

Agile languages and frameworks

These include Ruby on Rails, Python Web frameworks, and such.

work in progress

SOA

work in progress

Linking Open Data (LOD)

work in progress

Attempto Controlled English

(A near-random selection to get this section going)

ACE is a subset of standard English with a restricted syntax and a restricted semantics described by a small set of construction and interpretation rules. It can be a good way to express business rules, which can then be read by people and yet processed by machine.

ACE is useful in projects where there are many complex and rigorous rules in the problem space. It can be a useful tool for conceptual coherence. One problem might come about where people think they can construct ACE rules, looking at examples, but end up making subtle errors. This is something the architect can clean u[, or perhaps the architect becomes the sole keeper of the shared rules. More importantly, ACE is overkill for most projects. There is usually no need for machine interpretation, and it's far more important that Business rules are expressed in some shared way in the first place. If shared rules are expressed in simple, natural language that uses the specific vocabulary of the core concepts definition, this is usually enough.

Contrast with other software development methodologies

Jacquard is a system for Agile software development. It's obviously influenced by many other methodologies, but it's designed from scratch to emphasize needs for Web development. Many of the similarities and differences to other methodologies is discussed in the "Principles" section.

Rational Jazz

http://www-306.ibm.com/software/rational/jazz/

Similar focus on collaboration, but seems to also have more of an enterprise bent. Also seems fairly closely tied to a particular set of tools.

Where does Jacquard work?

Jacquard is not for every project. The following factors can be used to determine where this methodology is a good fit. If the answer to the first four questions is "yes", and so are more than half of the remainder, do consider Jacquard.

• Is this a project to develop a Web site or Web application?
• Is the organization set up to support rich, distributed communication?
• Is the organization set up to support rapid decision-making?
• Is there a strong candidate or team to server the role of the Jacquard architect?
• Is the project of a size and complexity to be completed in under six months, with iterations of a week to a month?
• Is the total number of people involved in developing the project two dozen or fewer
• Is the level of risk associated with project success low enough that it is not considered "life or safety-critical", and are delays or compromises to goals not likely to jeopardize the entire business?
• Are more than a third of the developers and UX personnel very experienced (more than 10 years of experience is a rough benchmark)

"Jack-who?"

Jacquard, after the man some people consider the first computer programmer. Joseph Marie Jacquard is considered by some the first programmer. You could consider him the first operating system designer, having created a device to be be affixed to looms. This device worked with a card with a pattern of holes, much like early computer punched cards, to direct the textile design. The connection between art and technology that led to this pioneering development in informatics is still alive and well in the area of Web development. Our methodology, one for weaving projects onto the Web, is named in Joseph Marie's honor.

See also

• "Perspective on XML: What is this ‘agility’?"

• http://www.boxesandarrows.com/