WEEK 6
Design and Development of e-Products:
The Product is the Process is the Architecture
Synopsis
We consider how to manage the development of service-products and design service-products for a dynamic e-Service environment. We also examine some industrial tools available for architecting an e-Service.
Readings
The process of developing and designing computers
and digital products ("The Flexible Approach") has been characterized
as being quite different from the typical design approach for physical goods
("The Traditional Approach"). The first two sections of the Rational
White Paper give a nice outline of the designers and the best practice
approaches in the WWW scenario. Marco Iansiti and Alan MacCormack, as you can
see, have published extensively on this topic of flexible product design. The
front end of the free Iansiti article provides their main insights in a couple
of paragraphs, and basically says the same thing as the others. If you happen
to own any of the others, feel free to substitute them for the assigned article
OR just substitute the summary of their findings from "Developing
Products on Internet Time" which can be found in a single paragraph HERE.
(Read - Sections 1 and 2) “Controlling the Chaos of Web Development,” Rational White Paper
http://www.rational.com/products/whitepapers/101066.jsp
http://www.rational.com/media/whitepapers/700602_Controlling.pdf
(Read - Up to section heading "Empirical Foundations", about 2-3 pages) Iansiti, M., “Shooting the Rapids: Managing Product Development in Turbulent Environments,” California Management Review, 38, 1, Fall 1995, p. 37-58.
http://www.mohansawhney.com/Registered/Content/TradeArticle/ShootingTheRapids.htm
(Must first register for free account at www.mohansawhney.com).
Iansiti, M., and A. MacCormack, “Developing Products on
Internet Time,” Harvard Business Review, September-October 1997. (Also
reprinted in Tapscott, D., (ed.), Creating Value in the Network Economy,
Harvard Business School Press, 1999, p. 91-106.
(Summarized in one
paragraph toward the middle of this review of readings on technological
innovation and modular design.)
MacCormack, A., "Product-Development Practices That Work: How Internet
Companies Build Software," Sloan Management Review, Volume 42, Number 2,
Winter 2001, pp. 75-84.
One school of thought on e-Service design is based on
designing an appropriate user-interface for the "front-office" of the
e-Service. Jakob Nielsen (http://www.useit.com/)
has evolved into the "guru" of user interface design for the WWW. The
first short article below is a critical analysis of the typical First Stage
("BrochureWare") and Second Stage ("Dynamic Catalog") user
interfaces on the WWW. The second short article discusses user interface
implications of the Third Stage's ("Distributed Object") approach,
based on the Microsoft .NET
strategy (which has objectives quite similar to the CORBA, Java RMI/J2EE/EnterpriseJavaBeans,
COM/DCOM, and Groove's COM/XML approaches/visions, which were
the subject of Week 4's torturous readings).
(Read) Nielsen, J., and M. Tahir, “Building Sites With Depth,” WebTechniques, February 2001.
http://www.webtechniques.com/archives/2001/02/nielsen/
(Read) Nielsen, J., "The Network is the User Experience:
Microsoft's .NET Announcement,"Jakob Nielsen's Alertbox, June 25,
2000.
http://www.useit.com/alertbox/20000625.html
Ellis, P., and S. Ellis, “Measuring User Experience,” WebTechniques, February 2001.
http://www.webtechniques.com/archives/2001/02/ellis/
Moran, R., “Powers of Observation,” WebTechniques, December, 2000.
http://www.webtechniques.com/archives/2000/12/moran/
The picture below gives some idea of the potential
extent of digital content sources to be bundled into a "service-product"
-- looks pretty messy to me. (Enhydra is basically a open-source application server
"solution" that allow developers to build e-Services with Java and
XML -- in case you're wondering.)
(Browse) Enhydra Enterprise Content Architecture (click below, then click on the image to see it larger)
http://enterprise.enhydra.org/project/aboutProject/index.html
Note: This gives some idea of the full breadth of sources
of content types to potentially design into an enterprise e-Service. It is very
cryptic, though.
To design the "navigational view" or
"process-outcome" (Rust and Oliver's term) for the
"service-product" in person-to-person services, service
operations/marketing/management books typically suggest creating a
"service blueprint", which is essentially a flowchart that (1) lays
out all of the "front-office" customer interactions and
"back-office" transactions, (2) links up the transactions through
arrows that show how the customer's "service-product" travels through
the system, and (3) attaches some time estimates to indicate the time it takes
to traverse the arrows in the "service blueprint".
Since e-Services are largely made up of digital content, software development
tools can provide similar tools for e-Services -- basically object-oriented
modeling tools for (1) site content "objects" such as HTML pages, (2)
supply chain "object" modeling, (3) enterprise "object"
modeling, and so forth. Some of these tools can automatically generate the
objects and the processes that create the objects or communicate between
objects, after they are visually designed. The prime advocates of this approach
are the Object Management Group, which
developed the Unified Modeling Language
(UML) which can be used directly or extended to model most any
"object" of interest to an e-Service, and Rational Software, which has
developed many tools for and books about the UML modeling approach. The
Rumbaugh article give a high-level overview of the basic ideas, and the figures
in the "e-Software Paradox" paper give some idea of the components
involved. If you are interested in this further, the Conallen articles
describe how the UML is has been extended to facilitate a CASE-based e-Service
design process for the WWW. The Fingar et al. article describes a made-up case
study using these tools. Finally, Argo is an open-source (free) UML modeling
system, written in Java, that can generate code for an e-Service -- just
in case you want to try your hand at it, or just look at a picture of a CASE
modeling tool for UML.
(Read) Rumbaugh, J., “Trends in UML and e-Development,” The Rational Edge, December 2000.
http://www.therationaledge.com/content/dec_00/f_uml.html
(Browse) “The e-software Paradox: Building Better Software Faster,” Rational.com
http://www.rational.com/paradox/index.jsp
Case
Components Crucial for E-Business Development
http://www.adtmag.com/Pub/mar2000/fingar_FE303.shtml
Note that the figures are missing from the
online article. Figures for this article are in PDF files here
and here. Each file is about 1 MB. This case is
actually Chapter 7 from the book Enterprise E-Commerce by Fingar et
al., which appears to be fairly revolutionary, in that it (1) is covering
topics that Harvard Business School Cases don't go near yet (I checked), and
(2) is being adopted by 30 top business schools' MIS MBA classes. I've found
the important portions of the book online (i.e. free), but Dr. Fingar told me
that a new book is coming out soon, which you may want to buy then.
Overview
OA.SYS
Technologies is a $900 million maker of computer systems for the business and
government markets. The focused vision of OA.SYS is to build customer computer
systems tailored to individual business needs. After many years of rapid
growth, OA.SYS now finds itself competing in a market characterized by many new
competitors, shrinking margins and increasing competition. They also find their
operations hampered by legacy mainframe applications, many of which have been
previously integrated together through an Enterprise Resource Planning (ERP)
system. A SWOT analysis leads OA.SYS to the conclusion that it must begin to
build e-Commerce processes for procurement and sales. John Dorfman, the
designated system architect for the architecture that will run the current and
future e-Commerce initiatives for OA.SYS, must make a decision about whether to
build, buy, or assemble an e-Commerce platform.
1. Compare the old procurement function of OA.SYS with their vision for the new procurement function.
2. What are the implications for the future "service-product" (i.e., goods, services, digital content) of OA.SYS? How will the integration of the procurement function affect the portfolio of goods (customized computers) sold by OA.SYS?
3. How will the component approach taken in building the procurement function affect the subsequent efforts aimed at building an e-Commerce front-end for customer purchase transactions?
4. Has OA.SYS potentially avoided some pitfalls by perhaps coming late to the e-Commerce game? By building their e-Service back office before their e-Service customer interfaces, do they potentially hold some advantages over competitors who have done the opposite (i.e., WWW site first, back end second)?