Object-Oriented
Knowledge Transfer

by Peter Fingar
with John Cribbs and Ron Schultz of KSC

.

Abstract
1 Some of the materials included in this paper have been adapted from the book The Blueprint for Business Objects,SIGS Books, New York, 1996 (see Suggested Readings, page 28).

Object-oriented information systems promise to make building and using technology easier for business and technology professionals. But first, developers and users of the technology must learn to think in funda-mentally new ways. Object orientation is a paradigm shift as clearly defined in Joel Barker's 1992 book, Future Edge. It is not just a new tool or technique, but an entirely new framework for defining and solving problems. The problem with a paradigm shift is that years of accumulated knowledge, skills and experience cannot be directly applied to the new paradigm. Not until the enlightenment or "aha" stage is reached (where an intuitive understanding of the new paradigm is gained) can past skills be adjusted and applied in the new framework. Transitions to the new paradigm must account for these human factors. These issues are addressed in this paper in order to provide insight for companies planning their migration strategies.

This paper focuses on the role of mentoring and multi-step training during initial technology transfer projects. Mentoring and team learning are essential to making successful transitions and in developing an organization that is capable of keeping up with the rapidly evolving technology. The paper concludes by outlining strategies for continuous learning.1

Next Generation Computing
Know-How

New Disciplines for IS

Our industry is on the verge of massive upheaval and change. The nature of the problems we are trying to solve cannot be fixed with the tools we currently use or with the problem-solving paradigm we have in our heads.The systems we need to build in the future are real-time, event-driven simulations of the business, not the transaction-processing, record-keeping reporting systems we built over the last 30 years." - Jim Stikeleather, Computerworld Client/Server Journal.

Robust, intelligent and human-centered information systems, the type needed for the competitive edge, cannot be designed and developed with the traditional data processing skill set. The next generation of computing will not come easily. Business and technology professionals must learn how to think in funda-mentally new ways. Mentoring and team learning are essential to building an IS organization capable of keeping up with the rapidly evolving object analysis and design methods and the new era applications resulting from business engineering initiatives. There are no short-cuts and no one-week programmer classes that bring about transformations. The knowl-edge needed to conceive, develop and implement next generation information systems is much broader and far more specialized than the knowledge needed for traditional data processing applications. Essential systems development knowl-edge must be expanded to include:

 general systems thinking, modeling and simulation

 human-centered design

 self-directed team manage-ment

 object-oriented software engineering.

It's a whole new ball game with new players and roles.

General Systems Thinking, Modeling and Simulation
Except for today's programmers and developers of real-time systems, modeling and simulation skills are not part of most commercial IS organizations. Yet it is precisely these skills that are needed to conceive, design and construct event-driven, distributed object comput-ing applications. Disciplines taught in mathematics and science provide the backdrop. As Professor Lewis Pinson explains, "Herein lies the problem: All too frequently, the COBOL programmer does not have the background required to be successful in the [C and C++] culture." He maintains that it is the "science" in computer science that is missing from many commer-cial developers today. "Consequently, the transformation of programmers without the prerequisite science background is slow, difficult and extremely painful."2 Rather than develop point solutions or single purpose

applications, object-oriented systems development relies on a new style in which developers are constantly building upon architectures and infrastructures to achieve productivity and reuse. Systems thinking is a core discipline for designing and constructing such infrastructures.

"The next generation of computing will not come easily. Business and technology professionals must learn how to think in fundamentally new ways".

Human-Centered Design

The information systems of the future must be simple to use, yet powerful. "Complex is easy; simple is diffi-cult." 3 The corporation of the future will rely on advanced information technology. And the only way technology can work is through information systems that mirror human cognition - the way people think when accomplishing work. Information systems must be created from human-centered designs, not technology-centered designs. They must be based in human cognition - they must be based in reality. Nippon Telephone and Telegraph (NTT), the Japanese telecommunications conglomerate, expresses its vision of future information systems as VIP: visual, intelligent and personal. Cognitive science provides the body of knowledge needed to practice the art of human-centered design and is a core discipline required by the teams that are tasked with developing next generation systems. The user interface must be much deeper than the pixels that make up a graphical user interface (GUI). The failure of commercial information systems to deliver human-centered, usable interfaces is well documented (see Zuboff and Norman in the Suggested Readings).

Self-Directed Team Management

Working in multidisciplinary teams requires sharply honed team skills for teams to be effective. The highly specialized backgrounds of individual participants mean that people with differing personalities, perspectives and ways of viewing problems must be integrated into an effective team structure. Real-time simulations and systems based in human cognition simply cannot be designed and constructed without multidisciplinary teams. The ability to manage and participate in diverse work teams is essential, and these skills must be learned.

Object-Oriented Software Engineering

Object orientation provides the framework for managing complexity of next generation systems, but object-oriented software engineering presents the commercial systems developer with a steep learning curve. Habits, ingrained ways of thinking and the mental models we use for problem-solving are very difficult to change. Thus, to transition a working professional to new ways of thinking and doing things is very difficult. This brief introduction to the disciplines required for developing next generation systems clearly raises a significant question: How do we learn this way of developing systems? Transitions should be carefully planned and executed, not left to chance. Let's examine the core competencies that are needed on an object-oriented systems development team by introducing a curriculum map.

An Object-Oriented Curriculum

If we consider the roles and competencies required on an object-oriented systems development team, we can derive an initial set of learning requirements. Table 1 shows who on the development team needs to know what. Competencies are listed in the leftmost column, and roles requiring the competencies are listed in the column headings.

In addition to the subjects listed in the table, note that highly specialized skill competencies may be needed by individuals participating in a systems development team. Further, individuals may not have the prerequi-site background to acquire skills in a particular subject. For example, a systems analyst may require one or more mathematics courses prior to undertaking studies of modeling and simulation. The individual development plans shown at the bottom of the table make the needs for individualized training apparent. No single curriculum can fit all individuals, and specialized training should be available to meet individual needs.


Table 1 An Example of an Object-Oriented Curriculum

The curriculum outline does not suggest that a person takes a course and, presto, competency is achieved. On the contrary, competencies in the subjects listed in the curriculum can take years to develop.

Mastery Levels

A common mistake made in transitioning an organization to any new technology is to perceive training as a binary proposition: People are either trained or they are not. Experience indicates that this is a flawed assumption. Meilir Page-Jones, president of Weyland Systems, developed a seven-stage model of what software developers actually go through as they learn and develop skills associated with a new technology.4 Developing an environment and a process to move people through those seven stages should be high on the CIO's priority list. The following discussion is adapted to Page-Jones' stages:

Stage 1: Innocent --- Never heard of the technology.

Most developers have heard of object technol-ogy, but their awareness is actually very low. Someone may be considered innocent if he has not learned enough about the technology to be aware of some of the engineering tradeoffs associated with it, some of its costs, some of its benefits, or where and when it might be appropriately applied. Moving someone from the innocent stage to the next stage is a process of providing gentle introductions to the technology through articles, presentations and seminars. The goal is to inform and educate. Management-level introductory presentations place the more global issues of the technology into perspective.

Stage 2: Aware --- Has read something about the technology.

At stage two, the person has become aware of the benefits and costs of the technology, as well as when and where it might be successfully applied. The person can generally describe what is involved with the technology, and at a high level can compare and contrast the technology with older approaches. The person has a talking knowledge of the technology. A person at this stage has not yet achieved the paradigm shift. His intellectual framework for the technology is still based upon drawing analogies to the old ways of doing things, and the person probably still draws upon erroneous assumptions when thinking or making deci-sions about the technology. Moving a person from this stage to the next involves establishing and executing an initial training program of classes, readings, seminars and workshops in the higher level concepts of the technology. With object technology, this training is in the areas of analysis, design and methodologies.

Stage 3: Apprentice --- Has studied the technology.

At this stage, the person is well aware of the high level concepts of the technology; however, he may or may not have experienced the paradigm shift. This person cannot effectively apply the technology on his own, but can begin to contribute to the use of the technology. Moving the person from this stage to the next involves establishing and executing a training program that focuses on the details of thetechnology. In the case of object technology, it is now appropriate to introduce language and tool training. At this stage and its transition to the next, hands-on training becomes very important. To this end, an apprentice should be teamed with a mentor, someone who uses the technology naturally and automatically and can explain the internal process involved with the technology. For the apprentice, it is sink or swim at this stage. It is time to throw the apprentice into a development project using the new technology. The mentor expects that the apprentice will swallow a little water and, at times, gasp for breath. Fortunately, the mentor serves as a lifeguard. The mentor has to closely monitor the apprentice to ascertain progress, capitalize on the lessons that are learned from mistakes, and adjust the detailed goals of the development process.

Stage 4: Practitioner --- Ready to use the technology.

At this stage, the person is ready to make engineering decisions on his own. There should be a continuing education program in place to increase his breadth of understanding of the technology and its applications. This is generally a self-managed process. This stage still needs the presence of a mentor to make assignments and observe results. However, detailed supervision should no longer be required. Mistakes are a significant contributor to the learning process at this level, and the practitioner should be allowed to make them. At this stage, the practitioner is given full responsibility for assignments and is an active participant in project review activities. Movement to the next stage is a function of time, experience, an increasing knowledge base and specific mentoring.

Stage 5: Journeyman --- Uses the technology naturally and automatically.

This is the stage that development staff should achieve by the end of the transitioning process. At this stage, participants are able to apply the technology in normal situations and do not require the presence of a mentor to accomplish quality work. This stage also requires a self-managed learning program to increase the understanding of the technology. This stage still calls upon the mentor when new or especially complex problems appear.

Movement to the next stage is a function of experience, increasing depth of knowledge, and the evolution of the generic, problem-solving framework. This problem-solving framework is developed through interacting with a Master-level person on new or complex situations. In this stage, the solution process is more important than the solution details.

Stage 6: Master --- Has internalized the technology and knows when to break the rules. This stage is self-explanatory, with continued learning a matter of keeping up with progress being made with the technology. Every organization needs access to a Master, either on staff or on retainer. The Master can handle new or complex applications of the technology, review Journeyman level work, show alternative or creative solutions to prob-lems, point out subtleties in the engineering decisions, and help keep the organization up to date. Movement to the next stage is strictly up to the individual. It is based on the individual's thought process and experiences. Moving up to the Expert stage generally requires the individual to be actively engaged in a broad range of applications of the technology in new or unusual situations.

Stage 7: Expert --- Writes books, articles, gives lectures and develops ways to extend the technology.

The Expert is at the pinnacle of the technol-ogy. He is generally recognized for his contributions to the industry, and is often asked to lecture or give presentations at national meetings for his peers.

In summary, knowledge transfer is the foundation for success in meeting an IS organization's goal of reengineering its software development process. Mentoring, in context of the seven-step process for knowledge transfer, can be an effective approach to building a lasting foundation.

Master-Apprentice Models

Early adopters of object technology deployed traditional classroom training approaches and found these methods proved insufficient. Successful organizations now realize that working on real business projects in a master-apprentice relationship accelerates the climb up the learning curve. We are interested in what the learner can do as a measure of what they know. Experience tells us that when we are dealing with a paradigm shift for experienced computing professionals, the real world, not the classroom, is the appropriate learning environment.

In the real world, as simply stated by the object training master, Peter Coad, "the example teaches." Successful approaches encapsulate learning with the process of delivery of real projects. Mentoring is the preferred learning method and, as such, IS organizations will need to commit to learning while doing.

Mentoring Responsibilities

"The JOOP Guide to Project Mentoring," published in March 1995, contains a listing of more than 250 providers of project mentoring. Mentoring, or more specifically, O-O mentoring, is all the rage. Fortu-nately, Ed Swanstrom's article precedes the guide and provides a caveat emptor for the buyer of these services. Swanstrom explains, "While it's already gone beyond fashionable to merely mundane to talk about O-O mentoring, the role remains fairly ambiguous. Stripped down, it's 'org-speak' for on-the-job training (OJT)."5

OJT is not a new teaching paradigm. It is the original teaching paradigm. Thus, those charged with the responsibility of mentoring others require a solid understanding of mentoring. Knowledge Systems Corporation (KSC) is recognized as the company that formalized the

When we are dealing
with a paradigm shift for
experienced computingprofessionals,
the real world, not the classroom,
is the appropriate learning environment.

apprenticeship and mentoring approach to object-oriented technology transfer. Today, several major companies have adopted and refined the approach, including IBM's Object Technology University, Hewlett-Packard's Professional Services Division and The Technical Resource Connection. A mentor is an experienced and trusted counselor. In business, a mentor is normally someone who is willing to teach you the ropes of the business --- the tricks of the trade. In technology, a mentor is all of the above: a wise counselor and an individual who will teach the tricks of the trade. Using the process of mentoring, an organization can be guided past the traps and pitfalls of object-oriented technology. A qualified mentor will advise, warn and train where necessary to prevent the failures that have plagued other organizations. Mentoring is the process by which a master object technician provides guidance to an individual object-oriented developer or development team on matters spanning the entire software engineering spectrum. The goal of these activities is to further the team's successful use of object technology. Typical mentoring activities include:

 reinforcement of prior knowledge obtained in classroom training or other learning experiences
 software engineering process guidance
 project planning guidance
 team capability assessments
 project progress reviews
 design and code reviews
 performance and tuning workshops
 configuration management process optimization
 establishing realistic project goals after assessing the learner's needs and capabilities
 providing just-in-time training on project-relevant advanced technology topics (e.g., memory management optimization, design patterns recognition, and real-time event processing) at the time new skills are needed to achieve project deliverables
 creating individual development plans for project members.

The mentoring approach to learning a new technology is generally the most effective in a one-on-one environment for systems architects and a one-to-three ratio for developers. The process of mentoring developers requires a focus on team learning as well as individual development experiences. Further, mentoring is needed at all levels, including for business executives. More and more information systems professionals will be asked to add mentoring to their core responsibilities. Mentoring does not mean learning by osmosis. An effective mentor understands the learning process, knows how to identify and document learning requirements and objectives, and knows how to arrange and manage the conditions for learning. The mentor is not just a tutor. In fact, a mentor may not actually do tutoring. Rather, the mentor manages the learning process of the apprentice. The individual development plan provides the mentor with a tool to document goals; learning activities and strategies to reach the objectives; and measures of results. Learning occurs everywhere and at all times. Individual development plans typically include work assignments, training assignments, college courses, conferences, Internet discussion groups, readings, research and other develop-mental activities deemed appropriate.

In summary, mentoring is a major undertaking and should be approached in a systematic and well-definedway. Mentoring responsibilities should not be taken lightly.

In addition to mastering the technology and its application, mentors must master the disciplines of adult learning if they are to be effective in transferring knowledge. Adult learning, especially in the context of a paradigm shift, is a challenge in and of itself.

The Problem of Adults Learning New Concepts

Business engineering teams are increasingly turning to object-oriented techniques to model business processes. In the future, the business model and the software model will become fused. Both business and computing professionals must learn to "object think" in order to gain the knowledge and skills needed for business reengineering. However, since object orientation involves a paradigm shift, the principles of adult learning must be carefully applied. One mainframe programmer who made the transition to objects described the essence of the new way of thinking: "In any kind of procedural language, you are breaking down work flow and coding it. In object-oriented design, you're breaking down events and assigning responsibilities to objects and not really dealing with work flow anymore."6 Once the new way of thinking is instilled, the syntax, grammar and complexities of object-oriented tools and techniques become manageable to the learner.

Adults have been sufficiently trapped in the boxes of life so that their capacity for learning "for learning's sake" is limited by time and energy constraints of real-life. The adults who run our businesses can be pesky learners. They demand a lot from learning services and experiences. They expect learning to be:

 available just before the knowledge and skill are needed for the job: just-in-time learning

 hands-on, from the beginning

 preferably skill-building training delivered in the privacy of their own office or workspace (sometimes to overcome any anxiety produced while learning with subordinates)

 on demand, when and where it is needed

 immediately applicable, customized to the immediate need

And, most assuredly, they want a mentor.

When a new concept sinks in, we have reached "aha." We have adapted our inner mental models. But now we have to test our new understanding with application. Our first few attempts at application will produce mistakes. The feedback from those mistakes will in turn continue to reshape our understanding. By the time we reach mastery, we no longer consciously know what we are doing: We just do it. With this description of learning in mind, it is easy to conclude that to shift to a new paradigm, a person must become two people. One continues to get today's hectic job done. The other learns the new way of doing business. Work teams transitioning to object orientation must continually grapple with these facts. Because reflective time is a scarce resource, work teams must manage it very carefully.

Once the new way of thinking is instilled,
thesyntax, grammar and complexities of
object-oriented tools and techniques
become manageable to the learner.

.

.

The Assimilation Process

Corporations require well-thought strate-gies for transitioning to next generation information systems. These strategies must consider the current business culture, technology culture and current knowledge and skill sets of both business and IS personnel. The transition to objects is not a transition in tools and techniques. It is an evolution into a new way of doing business and a new approach to business problem-solving. Transitions must be incremental and iterative. They must be evolutionary and steeped in today's existing business realities. Transitioning to the object paradigm is not a computer system "conversion," it is a process of assimilation. Furthermore, the process is one of risk and asset management. The massive investments that corporations have in existing information processing assets provide the life blood of current business operations. We are not "converting to a new system," we are designing new types of robust information systems that leverage existing corporate information assets. Preserving and integrating legacy assets into new era applications is not trivial and requires significant experience and expertise.

Successful technology transfer requires initial help from outside masters who have gone before. Smart business people learn from smart scientists and climb on the shoulders of others. They will discover that it takes several years to master the technology from scratch and that experienced object-oriented developers are in high demand and hard to find. For these reasons, out-sourcing can be an effective business strategy. Providers of object-oriented consulting, training and technical implementation are growing in number and size. Multi-year partnerships are being established between these technology providers and progressive companies determined to deploy the emerging technology for competitive advantage.

A typical arrangement may include the following general steps:

1. The outsourcing firm provides initial education and overall planning assistance.

2. With assistance from the outsourcing firm, the corporation develops a plan of action for a pilot project.

3. The outsourcing firm arranges initial training for the work team, and the pilot project is used in the training so that immediate application of the new skills is assured.

4. The outsourcing firm provides mentoring and coaching throughout development of the pilot project.

5. Pilot projects are expanded in scope, and steps 1-4 repeated. Each iteration reduces the need for outside assistance.

Transitions must be incremental and iterative.
They must be evolutionary and steeped in today's
existing business realities.

As technology transfer progresses, in-house team members can evolve into consultants to other corporate projects. The goal of successful technology transfer is self-sufficiency in the new paradigm. Self-sufficiency is achieved when the consulting firm is no longer needed and the expertise is entrenched in the business. In other words, the new approaches are mainstream.

Actually, long-term relationships will likely emerge, especially between corporations and business object providers, companies that develop industry-specific class libraries for object-oriented information systems. In the future, corporations will forge long-term relationships that blend the right mix of software acquisition, training, consulting, systems development and technical implementation. Depending upon cost / benefit analyses, any or all of these resources may be insourced or outsourced, or this way today and that way tomorrow.

Although these beginnings are small, they can scale-up in an orderly fashion. Beginning with proof-of-concept projects, a corporation can kick the tires, initiate low-risk demonstration projects, establish a corporate Object Technology Center (OTC) to provide a focal point, and develop learning processes to expand the initial knowledge base. This overall process is shown in Figure 1.

Figure 1 Overall Technology Transfer Process

Since the corporate goal is the insertion of object-oriented technologies into an already complex environment, successful transition strategies must start small, build proof-of-concept prototypes, increment the scope of the problem domain, and iterate.

Enterprise Learning Architectures

The key to successful transitions is to take small, incremental steps. Each step requires three fundamental learning actions: inform, educate and train. As shown in Figure 2, these three fundamental activities provide a blueprint or architecture for learning that can be applied throughout the process of developing next generation know-how.

Figure 2 A Learning Architecture

Inform

Object-oriented technology is evolving very rapidly. People working with the technology must keep abreast of both the fast changing technology and the company's plans and projects that involve the technology. Regular briefings, seminars, telecasts, newsletters and other means of company communications can accomplish the following:

 Provide all employees with a working knowledge of technology and how it is being deployed in the business.

 Foster a better understanding of the cross-functional work groups that are developing and supporting the technology infrastructure and the new object-oriented applications.

 Explain the roles and responsibilities of work groups and their relationships to other work groups.

 Keep all employees informed about changes and new plans for technology resources within the enterprise. Staying informed involves establishing pipelines to information resources. The professional wishing to keep up will want to subscribe to new publications such as Object Magazine and the Journal of Object-Oriented Programming, and Internet news groups such as comp.object. The number of books being published on the topic is growing as rapidly as the technology is evolving. Corporate and IS libraries can significantly contribute to keeping business and technology professionals informed by acquiring up-to-date books on the emerging technology and business engineering.

Educate

While training is key to acquiring the skills needed, concepts and theory are prerequisite to training. Exploration and discovery are key goals of educating. Learners should be rovided with a non-threatening, non-pressured opportunity to learn new concepts. As the goal is to develop "a new way of thinking," educational activities must be learner-friendly: fun, interactive, easy, challenging and engaging. Let's develop the big picture before facing the many details and techniques of the technology. Since we are reshaping existing mental models, we must be careful to meet the learners where they are as they participate in educational experiences. Education means formulating concepts and learning first principles in the new paradigm. Conceptual learning is prerequisite to learning new skills.

Train

Being informed helps us understand the "why." Being educated in the basic theories helps us to learn "what." Training provides the "how-to." A complete road map of the training process is developed in the next section of this paper. As we will learn, training should be centered in doing. The most effective means of learning a task is to perform that task. To be effective, the performance of the stated task must be based on actual project deliverables.

Once a step has been completed, the scope can be expanded, and the next iteration can proceed with additional information, education, training and experience. The transition requires learning through discovery as there are no cookbook or silver bullet solutions. Learn a little, apply a little; learn a little, apply a little. Each iteration increases the overall understanding of the object paradigm and the deepening understanding fosters better decision-making for the next iteration. Let's turn our attention to taking the first step in transitioning to next generation computing, the initial technology transfer.

Initial Technology Transfer

Rather than explain a theoretical approach to initial technology transfer, the following discussion is based on the approach that Knowledge Systems Corporation (KSC) has developed and refined over the past six years. The intent is to use KSC's proven approach as exemplary, but not as the only approach. KSC's core competencies are centered on Smalltalk environments, but the learning process presented here may be generalized to serve as a model for C++, Java, or other implementation environments.

Figure 3 depicts KSC's process for transitioning organizations and individuals from traditional development environments to object-based projects. This is referred to as KSC's Multi-Step Training Program. The program begins with theory-focused training and hands-on exercises that are presented in a traditional classroom environment.

Figure 3 The Multi-Step ProcessThis approach starts with transferring knowledge about object technology fundamentals, then transitions to the application of the fundamentals on a client project. Mentoring activities complement the overall strategy.

Development team members are then given an opportunity to apply the theory that they've been taught to a project of their choosing. This project-focused training is centered around the Smalltalk Apprentice Program SM (STAPSM). Following the STAP are a series of mentoring activities where the development team receives custom, individualized mentoring as necessary to supplement the more formal training activities.

Theory-Focused Training

A wide variety of courses is required to meet the needs of software engineers and managers involved in object-oriented implementation efforts. A subset of the required courses and their recommended completion for different project roles appears in Table 1, An Example of an Object-Oriented Curriculum. To optimize their effectiveness, courses must share a common educational philosophy of learning by doing. In keeping with this approach, hands-on exercises make up between 50-60 percent of class time. In classes where computers are necessary, each student is given his/her own machine to maximize the opportunity to explore topics independently. Instructors encourage student discovery by giving hints instead of direct answers to questions, thereby furthering the learning by doing approach. Pragmatic problem-solving is encouraged by the requirement that instructors have real-world experience in the subject matter they are certified to teach.

Project-Focused Training

Project-focused training takes over where the classroom education ends. Project-focused training goals are to help developers apply the theory learned in the classroom to a project they've been tasked to deliver by their management. These activities help students internalize the previously presented lessons while facilitating significant progress on the organization's development tasks. The core activity in the project-focused model is its Smalltalk Apprentice Program (STAP).

The instructor for a STAP is referred to as the STAP Master. The STAP Master acts both as an instructor and also project leader for the term of the STAP. The STAP model is shown in Figure 4. The STAP is 10 weeks in length with half of that time spent onsite at KSC and the other half working at the client's home office on the project.


Figure 4 Smalltalk Apprentice Program (STAP)
The STAP provides an intense, project-focused education event to "make real" the O-O training received.

The rationale for the time spent at a remote training facility is twofold. First, it is virtually impossible for any single individual to possess all the technological expertise required by today's typical application development project. The time at KSC allows the STAP Master to draw on additional staff with the expertise required to ensure the success of the STAP students. Second, apprentice programs are designed to be intense, high-productivity learning events. Removing the students from their offices and any associated distractions (e.g., meetings, phone calls, faxes, etc.) allows them to concentrate on the task at hand: object technology transfer and the application of object technology to their project.

The initial activity in the STAP is the Finding Domain ObjectsSM (FDOSM) workshop. The objective of the FDO is to produce an initial domain model for subsequent use in an apprentice program. The resulting model includes domain object definitions, class definitions, class relationships, responsibilities and contracts. The FDO is typically given at the client's site where one design "master" facilitates the activities of six or more client developers and users. The FDO is immediately followed by a week of Independent Development and Exploration (IDE). IDEs are interspersed throughout the apprentice program. They serve as unsupervised times where client developers work independently of their mentors to extend the results of the supervised sessions (e.g., models, software). This time helps the students gain confidence in their abilities to use the object-oriented techniques and technologies on an independent basis. Following the IDE week is the STAP itself. The STAP is divided into three segments --- each of which is separated by IDE weeks. The initial two-week segment is spent extending and implementing the

domain model that was a byproduct of the FDO. After having two weeks to work independently, the students return to begin work on their application models. This development phase includes implementation of the GUI interfaces and any interfaces to external databases. There is an additional IDE week followed by the final week of the STAP. This last week is typically spent on performance tuning, system packaging, and planning for the next iteration in the development lifecycle.

A variation on the STAP that is useful with larger development teams is the Parallel STAP shown in Figure 5. In this model, all members of the development team participate in the same FDO. One additional deliverable from the FDO is a partitioning of the domain model between the project sub-teams that will be working in parallel apprentice programs. STAPs then progress in parallel. Periodically, as the STAPs move forward, the teams are brought back together to share the work they've done independently. This ensures that at the end of the STAP, the individual application components can be smoothly integrated toform the basis of a working system.

Figure 5 Parallel Smalltalk Apprentice Programs
This STAP variation is useful in large integration efforts.

Figure 6 shows the STAP Just in Time model. This model is most useful when the client's application is reasonably complex and will use sophisticated technologies beyond what are normally available in an off-the-shelf Smalltalk development environment. The basic idea is to defer the classroom education events until the point in the STAP when they are to be used. Then replace the appropriate IDE weeks with the desired classroom training activities. In Figure 6, it was determined that the target application will need to use some of the techniques taught in an Advanced Smalltalk course. Also, the application will be using an object-oriented database management system (ODBMS) and training will be required in this technology prior to its use. Instead of "front-loading" all the classroom education events, they are interspersed throughout the STAP at times closest to their project introduction.


Figure 6 Smalltalk Apprentice Program - Just in Time

Gearing Up for the Long Haul

The introduction of object technology and architectures should not be viewed as a one-time event. The technology and distributed computing architectures will continue to evolve rapidly. As technology becomes more of an enabler for business change, keeping current and properly applying it to business problems will become a critical success factor for business.

Although the need for master-level knowledge and skill is obvious in the technology transfer phase of corporate transformations, the master-apprenticeship approach provides long-term benefits. Those who were apprentices during a technology transfer endeavor will grow into master roles as transitions spread throughout an enterprise. Corporate work teams, charged with ongoing process innovation and learning, will benefit from sustaining this working and learning model over time.

To conceive, design and implement a
learning organization to meet the enormous,
diverse and widespread needs of corporations
in the next century,
the process of corporate learning
must be reengineered.

The follow-up to initial technology transfer is developing a visible network of internal masters whose job it is to push the envelope of knowledge, technology and technique. Corporations can establish Object Technology Centers to serve as the focal point. Mentors, provocateurs, top guns and champions will be in continual demand as new projects come on stream. The process of deploying professionals in these or similar roles can be formalized and made a visible part of an Object Technology Center. As new process engineering projects come on stream, masters are needed to mentor and inject fresh concepts and perspectives. They are essential catalysts needed to stir team chemistry and trigger team actions.

To conceive, design and implement a learning organization to meet the enormous, diverse and widespread needs of corporations in the next century, the process of corporate learning must be reengineered. In his book, Re-Educating the Corporation 7 , Dan Tobin provides the rationale, the principles, prerequisites and the foundations for a learning organization. He describes how a corporation can breathe life into a learning organiza-tion, how to embrace new ways of learning, and how to create a virtual training organization. In The Fifth Discipline, M.I.T.'s Peter Senge asserts that it is possible to create learning organizations. In addition to the cornerstone, systems thinking, he describes four other core disciplines required to build such an organization: personal mastery, working with mental models, building shared vision and team learning.8 These disciplines can be used to build the foundation of the successful corporation of the future. And they are prerequisite to maintaining the know-how needed for next generation computing.

Conclusion

The transition to next generation computing poses a major learning challenge. Corporate training, as usual, is not up to the challenge. Learning next generation computing requires doing - and doing in the real world with real business deliverables. Corporations that want to truly address the paradigm shift will address it and learn it in the real world, not the classroom. To achieve meaningful results, initial transition efforts should be built around a multi-step technology transfer process that centers on live business projects. Companies that learn how to learn next generation computing will be the pacesetters in their industries.

References

1 Fingar, Peter, The Blueprint for Business Objects, SIGS Books, New York (1996).
2 Pinson, Lewis J., "Moving from COBOL to C and C++: OOP's Biggest Challenge,"Journal of Object-Oriented Programming, p. 54 (October 1994).
3 Stikeleather, Jim, "Complicated Simplicity," Computerworld Client/Server Journal,
p. 67 (April 1995).
4 Page-Jones, Meilir, "The Seven Stages of Expertise in Software Engineering," American Programmer (July/August 1990). Page-Jones can be reached at 76334.1247@compuserve.com
5 Swanstrom, Ed, "Beyond methodology transfer: O-O mentoring meets project management," Journal of Object-Oriented Programming (March/April 1995).
6 "Mainframers Transition," Computerworld, p. 103 (March 14, 1994).
7 Tobin, Daniel R., Re-educating the Corporation: Foundations for the Learning Organization, Oliver Wight Publications, Inc. (1993).
8 Senge, Peter M., The Fifth Discipline: The Art and Practice of the Learning Organiza-tion, Doubleday/Currency (1990).

Suggested Readings

Barker, Joel Arthur, Future Edge: Discovering the New Paradigms of Success, W. Morrow, 240 pp. (1992). Since the pace of change shows no sign of slowing, successful businesses will learn to stay alert to and systematically study paradigm shifts. Barker instructs business to watch for the surprises, not extrapolate the past. The book was reprinted in paperback in 1993 under the title Paradigms: The Business of Discovering the Future, Harper Business Edition.

Fingar, Peter, The Blueprint for Business Objects, Prentice Hall (1996).

Reviewed by Book News, Inc.: …Provides an overview of the emerging object paradigm in information technology, and a guide to using it, for business and information systems professionals involved in reengineering. Discusses issues in continuing education and training, and offers a curriculum model for object-oriented information systems development, plus a list of 26 practical strategies. Contains profiles of companies successful in object training, appendices on print resources, and a guide to usable interface design for object-oriented systems. Annotation c. by Book News, Inc., Portland, Or.

Love, Tom, Object Lessons: Lessons Learned in Object-Oriented Development Projects, SIGS Books, 256 pp. (1993). Love's highly readable book focuses on building large-scale commercial software projects using objects. The book provides clear insight into the issues and trends as opposed to specific products and services. Love brings more than a decade of experience to this work. The book examines the many questions that technical leaders and managers face as they transition to object technology.

Norman, Donald A., Design of Everyday Things, Doubleday (1990); Things That Make Us Smart, Addison/Wesley (1993); Turn Signals are the Facial Expressions of Automobiles, Addison/Wesley (1992); User Centered Systems Design, Lawrence Erlbaum Assoc. (1986). Norman is the founding chair of the Department of Cognitive Science at the University of California. Developers of computer systems are well advised to read Norman's work.

Senge, Peter M., The Fifth Discipline: The Art and Practice of the Learning Organization, Doubleday/ Currency (1990). Senge's focus on "systems thinking" represents a discipline that is central to business processes. This work has had a major impact on business reengineering.

Tobin, Daniel R., Re-educating the Corporation: Foundations for the Learning Organization, Oliver Wight Publications, Inc., 289 pp. (1993). Former education manager at Digital, Dan Tobin brings more than twenty years of training and development experience to the pages of this widely read book. The book provides a complete blueprint and practical tools to create virtual training opportunities and to build a dynamic learning organization.

Zuboff, Shoshanah, In the Age of the Smart Machine: The Future of Work and Power, Basic Books, 468 pp. (1988).

Zuboff, Shoshanah, Psychological and Organizational Implications of Computer-Mediated Work, Center for Information Systems Research, Alfred P. Sloan School of Management, M.I.T., 26 pp. (1981).