This chapter covers the management processes and structures that lead to successful transitioning of IT work offshore. These are lengthy, subtle, and difficult processes that require close managerial attention. We cover three key transition topics in this chapter, and each one of these topics can be read by itself and does not require linear-style reading. The topics are augmented with case studies and examples. The three topics are:

• Knowledge transfer. The process of successfully transferring specific types of knowledge and experience into the minds of all those collaborating on the work across many kilometers.

• Change management. Overcoming the inertia and resistance within the organization to a difficult change.

• Governance. Establishing structures, roles, responsibilities, and written agreements to ensure that control, coordination, and relationships are all functioning smoothly between the client and the provider in offshore out sourcing.

Knowledge transfer

Knowledge transfer deals with moving specific kinds of knowledge and experience into the minds of the people collaborating on the software work. Some of the knowledge transfer is from home location to offshore location; some of it goes the other way.

Why voice? Business communication is mostly about paperless paperwork, right? Computer workers like you and I stare intently at the computer screen for long hours, and by the end of the day are ready to kill the computer.

“A picture is better than a thousand words” applies only when it is not a picture of a thousand words that we read on our computer screens every day. Voice components bring some relief to our eyes and allow us to listen to text pages and even to talk back. (We talk more about speech recognition systems in Chapter 12.)

This chapter is about integration with voice components based on free, downloadable Java libraries. Voice components make even more sense in devices with small screens, or no screens at all.

The news watch is an example in which the voice component would be highly appreciated. Imagine a talking watch that delivers the news. Someone could use the screen option in a crowded place and the voice option in a better environment—for example, outdoors.

We add a voice component to the news watch at the end of this chapter. Right now, we take a closer look at synthesis technology.

WHAT IS THE BASE FOR CREATING A VOICE COMPONENT?

The free text-to-speech (FreeTTS) library was built by the Speech Integration Group of Sun Microsystems Laboratories as the first, though not complete, implementation of the Java speech application program interface (JSAPI) [1].

This chapter turns the smallest Java Virtual Machine (JVM) running on a smart card into a powerful key that can open all doors.

WHAT IS A SMART CARD?

Imagine a regular plastic card (often called “plastic”) with either a microprocessor and/or a memory chip embedded into the card. The microprocessor can manipulate information on the card, whereas a memory chip (e.g., the one in a prepaid phone card) can undertake only a predefined operation performed by a card reader.

Smart cards, unlike magnetic-stripe cards, do not require remote access at the time of the transaction; they can carry all the necessary functions and information right on the card. Today, there are three categories of smart cards: microprocessor, memory, and optical memory.

Microprocessor cards have an 8-bit processor, 16 KB of read-only memory, and 512 bytes of random access memory. Their processing power is similar to the first personal computers. These cards can perform cryptography algorithms and are used to access, hold, and otherwise manage digital money; provide secure access to computer and phone networks; secure set-top boxes; and perform other functions.

Memory cards, which can hold up to 1 to 4 KB of data, represent the bulk of the 600 million smart cards sold last year, primarily for prepaid, disposable card applications like prepaid phone cards. Card readers (also known as card-accepting devices) perform fixed operations (e.g., add, subtract, and delete) on memory cards.

Optical memory cards have a piece of (optical) compact disk glued on their surface. Up to 4 MB of data can be stored on the card, once and forever.

This chapter is about speech technologies and related APIs: VoiceXML, SALT, Java Speech API, and MS Speech SDK. It looks into unified scenarios with audio/video interface (AVI) definitions, considers design and code examples, and introduces important skills for a new world of wired and wireless speech applications.

WHAT IS A NATURAL USER INTERFACE?

Is a natural user interface (NUI) another set of tags and rules covered by a nice name? Absolutely not!

This time, end users—not a standards committee—make the determination on what they prefer for their methods of interaction. An NUI allows end users to give their preferences at the time of the service request, and to change them flexibly.

Are you a “computer” person?

My guess is that you are, because you are reading this book. “Computer literate” folks like you and me enjoy exploring the capacities of computer programs via traditional interfaces. Even so, there are times, such as when we are on vacation, on the go, and in the car, when we prefer “hands-free” conversation rather than using keyboards to access computerized services.

One person prefers handwriting, and someone else is comfortable with typing. One would like to forget keywords and use commonsense terminology instead. Can a computer understand that “find” is the same as “search,” and “Bob” is actually “Robert”? Can it understand that someone has chosen a foreign (non-English) language to interact with it?

“Write once and run everywhere” is one of the most important promises made by Java technology. Java Virtual Machines running on different platforms support this promise. With Microsoft's .NET initiative also you can write a program in C, C++, C#, Visual Basic, Perl, and so on. Then you can convert the program (with Visual Studio .NET) into the Microsoft intermediate language (MSIL) binary code that can be executed on any Windows platform by a virtual machine called the Common Language Runtime (CLR).

Unfortunately, the problem has many sides, and no technology by itself can help in every direction. Again, this is about the right development process coupled with the right technologies. What are the factors, other than language and compatibility problems, that prevent us from writing once?

When we try to use an existing service or application with a new environment, we find out that it does not fit. When business requires change and we want to adapt an existing product to that change, we find that there are no adaptation mechanisms in place. We realize that the basic properties, methods, and operations of the application are too specific to and too tight with the existing environment. The product has to be redone, often from scratch.

This chapter reveals the dependencies between a natural user interface (NUI) and knowledge technologies; discusses architecture, design, and code samples that integrate knowledge technologies into enterprise applications; and gives the keys to a new breed of software— “Softology,” a mix of software and ontological engineering.

We talked about NUIs in the previous chapter and agreed that they are not a trivial pursuit. We discussed at length a small part of an NUI—current speech technologies—and ended up with the conclusion that they can do a decent job when using machine-directed dialogs with multiple choices but are not quite ready to understand natural language spoken by a person.

We face similar difficulties with machine translation from foreign languages. I worked with multiple language translation programs that produced nonsense text filled with the right words.

WHY ARE COMPUTERS STUPID? WHAT IS MISSING?

Can tasks such as machine vision, speech recognition, and foreign language translation, which all seem very different, have a common solution?

The first common denominator is easy to find: all these tasks belong to the field of data interpretation. The next move is to find common steps for all three activities. What do people do when they are engaged in image or speech recognition, when they translate text from Hebrew to English? Why can't we build a program to perform similar steps?

The very first step is to recognize a business (social) domain area in which the data belong.

SOFTWARE ARCHITECTURE—THE CENTER PLACE OF SOFTWARE DEVELOPMENT

Software architecture is the highest level of a software system definition that can include subsystems with their own architectures. The main question is how deep one should go into the nested abstractions to define software architecture. The general answer is to stop right before implementation details that can be considered “private” parts of the design. More visible and exposed “public” containers, components, and connectors of the system with their run-time behavior and relationships comprise software architecture.

Software architecture has its own worlds of “what,” “why,” and “how”. The what world is mostly inhabited by industry standards, tools, and modules. The how world is about development process, design patterns, and architectural styles. The why world is a map between requirements criteria and the worlds of what and how. Design patterns [1, 2] and architectural styles [3] are very close by their nature but different in their scope and manners. Both are symbol names and concepts that describe approaches to common development problems.

Multiple architectural views work as light projectors helping us to see the systems from different sides by eyes of different parties interested in the product.

ARCHITECTURAL ELEMENTS, STYLES, VIEWS, AND LANGUAGES

Most of today's enterprise applications are built with object-oriented architecture, in which system components encapsulate data and behavior and communicate via messages.

Components, containers, and connectors are basic elements of the architecture.

In this appendix, you will find practical examples of how to:

• Start a collaborative service

• Read/write geographical data

• Use Java Naming and Directory Interface (JNDI) for multiple types of data sources, including domain name servers

• Share a screen with multiple users (great for troubleshooting and demos!)

• Use Java Media Framework (JMF) and Java Message Service (JMS)

• Create speech recognition and text-to-speech (TTS) applications in C#

• Spam and Spam Killers

• Improving efficiency and reliability of your email server

• Create a distributed knowledge systema and join educational/knowledge alliances.

These are the main targets, but the list can go on and on. You will find basic source examples in this appendix, and you can download more from this book's support Web sites at Cambridge University Press (www.cup.org/titles/ 0521525837.htm) and ITSchool, Inc.(www.JavaSchool.com).

GETTING INTO COLLABORATIVE SERVICES

Ben was always good with computers; some cosmic adventure games even followed him in his dreams. He was also very open to sharing or (using the impressive word) “collaboration.” He opened his first collaborative Web site when he was very young. He often had to stay home sick, and the site helped him to keep in touch with his kindergarten class. All his teachers and friends received his invitation-links to the site, except for Peter, a boy who never shared his piece of cake with anyone.

This appendix is a reference to Java, including the JDK1.5 and C# languages. In previous chapters, we discussed integration-ready and knowledge-connected environments that allow for writing application scenarios. In spite of the fact that most examples that support this method are made in Java, similar environments can be created with other languages. Life outside of Java is not as much fun, but it is still possible.

This appendix provides examples in which the same function is implemented not in Java but in its easiest replacement—the C# language.

This lucky child inherited good manners, elegance, style, and even some clothing from its stepfather while enjoying its mother's care and her rich, vast NETwork.

Java and C# are similar in their language structure, functionality, and ideology. Learning from each other and growing stronger in the healthy competition the siblings perfectly serve the software world.

JAVA VIRTUAL MACHINE AND COMMON LANGUAGE RUN-TIME

Java compilation produces a binary code according to the Java language specification. This binary code is performed on any platform in which a Java Virtual Machine (JVM) is implemented. The JVM interprets this binary code at run-time, translating the code into specific platform instructions.

C# compilation (through Visual Studio.NET) can produce the binary code in Common Intermediate Language (CIL) and save it in a portable execution (PE) file that can then be managed and executed by the Common Language Runtime (CLR).

Collaborative engineering is an important subject that is currently missing in schools, although some courses include a few of its aspects. I doubt I can cover it all at once, but I will try my best to integrate development technology and the development process under one roof, where integration-ready systems can be created.

Technology tends to fragment: to focus on pieces and omit the glue. The development philosophy that I associate with the terms of collaborative engineering helps keep a better balance between a narrow focus on particular components and their multiple connections to the rest of the world. The practice of collaborative engineering also assists in establishing a repeatable—yet flexible and constantly improving—development process. This is the foundation for integration-ready systems development.

What is collaborative engineering all about? It is about the development process in its organization, management, and methodology, integrated with innovative development technologies. I have had the privilege of teaching corporate developers and architects in the United States and overseas. Many times, I have had the amazing feeling that some of my brightest students, experienced developers, knew all the pieces of the puzzle and still could not start putting them together.

For example, almost every programmer knows one of the main design rules: Separate business from presentation logic. However, there are still more cases that break this rule than cases that follow it. One of the hardest questions is how to apply the rule properly.