A Must-Read for Architect and System Integrators
Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services by Thomas Erl, Prentice Hall, 2004, ISBN 0-13-142898-5, 560 pp., US$39.99.
Of the many books that cover Web services and service-oriented architecture, Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services will certainly go down in history as one of the best. It's the only book of its kind that covers the latest and the greatest Web services protocols and integration techniques, such as second-generation Web services protocols. Thomas Erl doesn't hesitate to mention that the road to SOA is paved with good intentions and failed projects, and it's a risky undertaking. Erl walks readers through the migration, integration, and reengineering process step by step.
The book's organization is unique: Erl starts with simple, even trivial information, such as introducing XML, document type definition, XPath, and other native protocols—including universal description, discovery, and integration (UDDI), the Web Services Description Language, and SOAP. Then he covers second-generation Web services protocols, including WS-Security, WS-Coordination, WS-ReliableMessaging, WS-Transaction, and the increasingly complex WS-Policy. Only a few pages cover the native and older protocols, but the book covers second-generation protocols in detail with accompanying examples and code snippets. To my knowledge, Erl covered all major protocols. Research is always happening, but Service-Oriented Architecture gives readers a fairly well-rounded understanding of the protocols they need to know to benefit from service-oriented architecture and methodology.
One of Erl's major goals is to help the reader think differently about XML. He sets the stage by denoting XML as a new way of
• Thinking about data. Instead of thinking about data in a flat fashion, you need to think in an object-oriented manner.
• Representing data. Object orientation represent data in new ways, and XML becomes more than just a couple of brackets you add here and there.
• Representing business rules. XML's metadata capabilities let you represent rules about your business and data.
• Choosing an architectural platform. XML's protocols and enabling technologies let you choose from numerous architectural patterns such as database access patterns, data representation patterns, and business rules representation.
• Designing applications. XML lets you exploit a new architectural platform by approaching your design in a new light.
• Programming data access. Parsing XML, creating XML data, accessing databases, parsing business rules—various XML technologies let you access your data in many ways.
After the first few chapters, it's clear that SOA is more than just integration—it's a new way of thinking about architecture, design, and implementation. This new approach must start from the bottom up, and chances are the way we've been thinking about XML and its surrounding technologies and protocols is wrong. Erl clears up any misconceptions we might have about native XML technologies before he discusses SOA.
Erl then dives into the integration question. Again, he covers simple topics first and briefly, including XML integration and Web services integration, techniques, and databases. Application integration is more interesting, and Erl covers it in more detail. The section is useful for its discussion of middleware technologies and evaluation, among other things. Because integration is tightly coupled with middleware and, more specifically, message-oriented middleware, an entire section covers middleware evaluation and techniques. This section is extremely useful for any organization going through integration. After discussing various middleware design patterns, such as hub-and-spoke, broker, messaging bus, and the enterprise Service Bus, Erl demonstrates the pros and cons of each pattern through examples and discussion.
The end of the book focuses mostly on integrating Web-services-enabled applications. It's not enough to simply enable your applications—how you integrate your applications after they're Web services is the key. Erl gives various application integration patterns from the simple to the complex—from legacy application integration to enterprise integration, and from wrapper services that act like adaptors to business services that are reengineered legacy applications.
Service-Oriented Architecture will probably be known as the first book to explain SOAs and migrating to an SOA. It's a step-by-step guide for succeeding with Web services; it's a software engineering course with new technologies and ways of thinking. And it's an easy read with pointers, hints, how-to's, tips, and comparison techniques that make it handy for any system integrator or architect.
is a solutions architect at Platform Computing and a freelance writer. Contact him at email@example.com; www.artsedighi.com.
Learning from Software Failure
Software Development Failures, by Kweku Ewusi-Mensah, MIT Press, 2003, ISBN 0-262-05072-2, 276 pp., US$35.00.
Successful IT Project Delivery: Learning the Lessons of Project Failure, by David Yardley, Addison-Wesley, 2002, ISBN 0-201-75606-4, 346 pp., US$31.99.
According to several recent surveys, few development projects deliver a complete working system that's on time and close to the estimated cost. One-quarter to one-third are cancelled before delivery; of the remainder, most are late and well over budget, delivering substantially less than expected. Software Development Failures and Successful IT Project Delivery attempt to explain why so many software projects fail and to help the reader avoid falling into the same traps.
An academic view
Software Development Failures focuses on projects that are abandoned during development and projects in which the software never meets the users' needs. Kweku Ewusi-Mensah takes an academic's view rather than a project manager's, and his book is stronger on analysis than practical guidance. Some readers might find that the style obscures the meaning. For example, the Software Project Characteristics chapter includes the sentence,
The postmodernist view of software development explicitly recognizes the need for a plurality and diversity of shared responsibilities for all the stakeholder groups involved in the development, so that all legitimate and relevant views will be heard and incorporated into the problem formulation.
The book addresses socio-organizational, technical, and economic factors affecting software development abandonment, as well as user perspectives on software development failures. Ewusi-Mensah includes examples from five failed projects: the Confirm travel reservation system, FoxMeyer's Delta pharmaceutical information and distribution system, the US Internal Revenue Service's Tax Systems Modernization project, Denver International Airport's baggage-handling system, and a confidential project from a medium-sized California electronics company.
Ewusi-Mensah revisits these five projects throughout the book to illustrate the different factors that contribute to project failure. Ultimately, using the same five examples is tedious. Software Development Failures is a useful guide to project-failure research and a valuable reference for undergraduate business computing or management courses; however, I can't recommend the book to practicing IT project managers or software engineers.
A practitioner's view
David Yardley's Successful IT Project Delivery is aimed directly at those people who influence a development project's success: business sponsors, project managers, IT professionals, consultants, and users. It's rich with practical experience and checklists.
Yardley illustrates his points with case studies, including successes, notorious failures (such as the London Ambulance Service, London Stock Exchange Taurus (Transfer and Automated Registration of Uncertificated Stock) project, Denver International Airport's baggage-handling system, the Ariane 5 rocket guidance software, and the UK Passport Agency), and case studies from outside the IT world, including the Piper Alpha oil platform fire and the Concorde.
The book covers a lot of ground, from IT systems' role in business processes through all the project stages to testing and implementation. Yardley discusses the CMM, risk management, quality, configuration control, requirements management, and team psychology. He describes four information systems methods (Structured Systems Analysis and Design Methodology, Dynamic Systems Development Method, Object-Oriented Process, Environment, and Notation, and Rational Unified Process) and two project management methods, Projects in a Controlled Environment (PRINCE) and Managing Implementation of the Total Project (MITP).
Successful IT Project Delivery is useful and will help reduce the risk of project failure if readers absorb and apply its lessons. But a strong copy editor could have made it better by blue-penciling the second foreword—a blatant advertisement for DSDM by its chairman, Barry Fazackerley—and the aphorisms Yardley attributes to himself in two chapters alongside quotations from Samuel Johnson, the Bible, William Shakespeare, and Seneca the Younger.
A stronger editor would also have highlighted sections where Yardley's summaries are controversial and need fuller justification. For example, Yardley writes, "The benefits of using Function Point Analysis, however, are now largely discredited amongst many IT professionals, but it still remains popular nevertheless." This is far too dismissive a statement.
Yardley makes other assertions that are simply absurd. He says that "Adopting Total Quality Management (TQM) within an organization undertaking IS projects results in defect-free computer systems ('zero defects') that meet users' current requirements and adapt easily to meet their future needs and expectations." If only it were so easy!
Despite these weaknesses, the book has a lot of merit, especially for project stakeholders who aren't IT professionals and other readers who are relatively inexperienced in the complexities of planning and managing large software development projects.
Both books share a major flaw: neither author gets to the heart of managing IT systems' great complexity. Where other engineers have long recognized the importance of rigorous requirements analysis in uncovering contradictions and omissions, software engineers talk breezily about use cases and prototypes. Where other engineers produce mathematical models of their system architectures and designs, and analyze system properties before building, software engineers draw box-and-arrow diagrams with no precise meaning, program in ambiguously specified languages, and hope to find enough errors through wholly inadequate testing.
If we are to transform our industry into the mature engineering profession that society needs, we'll need to make radical changes. Software Development Failures and Successful IT Project Delivery will help us avoid the most obvious reasons why projects fail, but our projects will still fail, if not as badly. Successful IT development projects need more than just excellent management. They need excellent engineering, too.
cofounded the software engineering company Praxis High Integrity Systems and is an expert witness in complex IT cases. Contact him at firstname.lastname@example.org.
Paula M. Bach
Mark A. Cohen
Interaction Design for Complex Problem Solving: Developing Useful and Usable Software, by Barbara Mirel, Morgan Kaufmann, 2003, ISBN 1-55860-831-1, 395 pp., US$44.95.
Interaction design defines how interactive products communicate their functionality to users and how users interact with these products. In Interaction Design for Complex Problem Solving, Barbara Mirel argues that software systems that solve complex problems ultimately fail and that software design must address not only ease of use but, more important, usefulness. Creating a tool that helps the user solve complex problems is difficult. However, Mirel presents practical guidelines for creating such software using interaction design.
Mirel's background includes both academia and industry—she's a visiting associate professor and research investigator at the University of Michigan, has worked as a cognitive engineer and senior manager of human factors, and holds a patent for visual discovery design. Mirel's extensive industrial experience gives the book a practical feel. Her expertise in information visualization and human–computer interaction give the book a solid foundation.
Interaction Design for Complex Problem Solving contains a comprehensive preface, introduction, and 10 chapters. The preface and introduction situate the themes, and the chapters help the reader understand the work that solves complex problems; design technical, social, and co-emergent systems; and think strategically. Unlike user interface and software design books, this book covers interaction design issues and case studies with respect to work and systems rather than being organized around traditional user interface and software design processes and methodologies.
The three sections frame Mirel's case for improving applications for complex problem solving. The various case studies, testimonials, data, and supplemental tables and figures that Mirel includes make the book an engaging read. Interaction Design for Complex Problem Solving is easy reading, offering a toolbox of resources for designing useful complex systems for every software development team member.
The downside (and the upside)
A potential drawback is that the book doesn't focus on how to design a functional, productive, and efficient system from a software engineering perspective. Instead, it addresses these issues from a social perspective—one that software engineers might not know. Paying attention to the issues at a higher level, however, can help organizations avoid the high cost of bad design.
Another drawback for software engineers is that the book is aimed primarily at human–computer-interaction specialists, although it applies equally well to software engineers. Mirel calls for a change in software engineering's focus on usefulness; for this change to occur, the entire development team must be involved—not just the HCI specialist. In addition, many development teams lack HCI specialists. For the book's approaches to be adopted, software designers outside the HCI community must read it.
Software designers will benefit most from Mirel's real-world scenarios. In particular, Chapter 4's two case studies examine the difficult problem a database administrator (DBA) encounters when troubleshooting an overloaded client-server network. The chapter first examines the troubleshooting practices the DBA uses and then follows with a design team's failed attempt at creating a data visualization tool to help the DBA. Showing the failed attempt first and then showing how to create a more useful tool effectively conveys how software designers can improve their systems' usefulness. Such real-world, concrete examples will be valuable to practicing software engineers who have faced similar problems and made similar mistakes.
Paula M. Bach
is a PhD student at Pennsylvania State University's School of Information Science and Technology. Contact her at email@example.com.
Mark A. Cohen
is an assistant professor of computer information science at Lock Haven University of Pennsylvania and a PhD student at Pennsylvania State University's School of Information Sciences and Technology. Contact him at firstname.lastname@example.org.