Submissions to smallTALK newsletter

Articles for publication in this newsletter should be sent to:

Curt Rostenbach

CCH Incorporated

4025 W. Peterson, Chicago, IL 60646

Phone: (312) 866-3447 10a-6p.

Preferred format is Microsoft Word for Windows, however ASCII text is fine. Internet address is 'rostenbc@cch.com' and through special arrangements, articles can be modemed or faxed for OCR interpretation, which is how paper submissions will be processed.

Any subject is acceptable (within editorial discretion), so feel free to put fingers to keyboard and pound out an article.

A Road Map for Object Technology Adoption

Sandra Smith, Digitalk Inc.

The following is a reprint of the overhead slides presented by Sandra Smith of DigiTalk, Inc. at the March meeting held at CCH Incorporated.

OBJECTIVES

* Key concepts of object technology

* Benefits of building a shared object model of a business process

* Why some projects succeed and why others fail

* Critical factors for success in applying object technology

* What object technology requires of an organization

* Road map for managing the transition to object technology

The Competitive Challenge

* Business Information Systems should:

- track & organize flow of business information

- provide an enterprise wide view of the business

- support key business activities

- provide reports

- be adaptable and flexible

- provide integrity of information

- be easy to use

Competitive Challenge

* Continuous Improvement in processes, technology

* Incremental risk; incremental reward

* Common element is reliance on improved information infrastructure

Paradigm Shift to Object Technology

* Separates component interface from implementation details

* Allows easy definition of new components from existing components

* Enables "componentization" of legacy software

* OT standards solve the delivery problems of host and OS independence and interoperability

Object Technology Solves Three Problems

* Need for rapid, incremental, iterative development of new systems

* Need to capitalize software, encouraging reuse of proven software parts

* Need to reduce post-delivery maintenance

+ Objects are enabling technology for true software components

Object Fundamentals

* Object = reusable software entity often emulating a real- world thing or concept

- maintains data

- specifies behavior

- communications with other objects

- has a life cycle

* Object Model = shared view of business process

* Application = set of cooperating objects to solve a specific task

- based on object model; utility objects & application specific objects

Levels of Object Reuse

* Utility Objects

- GUI components, OS and DB interfaces

- Application structure objects

* Business Objects

- Account, Customer, Invoice, Product, Inventory, Manufacturing Run

* Reusable Designs (Frameworks)

- Loan Processing Framework

- Order Fulfillment Framework

How Much Reuse?

* Utility objects are widely available

* Business objects + Framework are not yet available; companies are building their own

* Frameworks are an investment technology

* A Reasonable Goal: 60 to 70% reusable software

SUCCESS FACTORS

* FOUR TYPES OF PROJECTS:

- Small Pilot

- The Incubator

- Phased Replacement Application

- Large Systems

* Decide Goals, then choose a project model

* Most success with pilot and replacement model for initial project

* One full- time mentor for small

Small Pilot Project

* Often sponsored by Advanced Tech Group

* Non- critical IS application

* 2 - 3 person team

* Informal analysis and design methods

* 3 - 6 months

* Low risk; low cost

* No technical breakthroughs required

Small Pilot Goals

* Use as a learning lab

- Learn / evaluate tools and methods

- No expectation of useful product

- Extrapolate lessons to larger development

* Build a core team of Internal Mentors

The Incubator

* Small, short, focused effort to evaluate a technology that can turn into products

* Middle ground between research and development

* Small teams of 3-5 people

- Highly motivated, senior technical people

* Low risk; medium cost

* Seeking technical breakthroughs

The Incubator Goals

* Many incubator projects funded in parallel (technology farm approach)

* Quite a few are expected to "fail"

* Philosophy is to learn and benefit as much from failures as from successes

* Rapid prototyping with fast iterations to eliminate roadblocks, assess technical risk

Incubator Success Factors

* Commitment to the Process

* Right People

* Training is integral to the process

* Project Scope is well-defined

* Total immersion

* Frequent communication of progress and experience

Phased Replacement Application

* Often lead by technical visionary

* Important application, non-trivial

- often intended to replace an existing system

- phased in over time

* Team of 4 to 8 people

* Design methods vary

* 6 to 12 months

* Medium risk; medium cost

Phased Replacement Application Goals

* Validate a technology in "real- use"

* Use objects to solve a hard, real-world problem

* Develop a migration path for legacy systems

* Develop domain-specific frameworks

Phased Replacement Application Critical Success Factors

* Management Buy-In

* Strong design architect

- Success on a similar project with similar technology

* Well- defined problem

* Well understood business rules

Large System

* Objects have been "sold" as a solution

* Project is often mission-critical

* Part of a large-scale reegineering effort

* Dozens to hundreds of developers

* Formal design methods

* Several Years

* High risk; high cost

Large System Goals

* Reengineering to improve usability, performance, extensibility

- Order-of-magnitude improvements in a business process

* Technology Transfer

- Consultants and Mentors in house

* Redesign internal software development

- Integrated tool support

- New Methodology

Large System Challenges

* Multiple Skill Sets

* No methodology fits all

* Tool integration

* System architecture definition

* Scaling up to production from working prototype

* Avoiding "Analysis Paralysis"

Large System Success Factors

* Framework development starts early, undergoes several iterations

* Best people work on the hardest problems

* Methodology evolves with the project

* Technical architecture is viewed as critical to success

* Evolution prototyping + Phased development

* Hard problems tackled early

* Interdisciplinary teams (users, analysts, designers, developers, technical architects)

Project Model Selection

* First decide goals, then choose a project model

* Some models work better in specific cultures

- Incubator

- Large Systems

* Most successes with pilot and replacement models for initial project

* At least one full- time mentor for small to medium projects

* At least one mentor per subsystem for large projects

Some Guidelines for Project Selection

* Project should be visible within company

* Project should have management buy- in

* Not mission- critical

* Solves some aspect of a real business problem

* Do- able with limited resources

- Ten or fewer people

- Duration of one year or less

- Full- time commitment from team members

* Allow people to "fail"

Common Risk Factors

* Mapping between object model and database is often underestimated

* Training and mentoring is often short-changed

* Commitment to the process is critical

* Use Prototyping correctly:

- Help determine scope

- Help assess technical risk areas

- Help communicate ideas

- Living specification

- Learning lab

Success Story - Carlsberg

* Project: Order Management System

* Staffing: 1 Project Manager, 3 programmers, 1 consultant

* Background: COBOL; no OO; no CASE

* Training: 11 Days

* Tools: Smalltalk V, PARTS, PARTS Wrapper ADW

Success Story - Carlsberg

* Timeline: 10/93 to 02/94

* Data Model: 30 existing DB2 tables; 2000 SQL queries

* Business Object Model: 50 Classes / 500 methods

* Application Model: 25 part files

* RESULTS:

- Production system built & deployed in 4 months

- Manages all shipment tracking

Success Story - Carlsberg

* Observations:

- Project chosen had several key characteristics:

* Well-understood business process

* Limited in Scope

* Limited in Duration

- CASE for objects works! Automated the hardest task.

- Very skilled consultant

Success Story - Cargill

* Project - integrated shipping and tracking applications

* Staff - 4/93 25 people

- 1/94 140 people

* Typical Background - COBOL mainframe; some C/S, C, 4GLs

* Training- 1 month (product, OOD, database)

Success Story - Cargill

* Tools: Smalltalk/V, Team/V, PARTS

* Classes: close to 2000 between development environment and application

* Consultants: 50% at start

* RESULTS:

- Complex, distributed, production- quality application built in new technology in ~l year

- Worked first time it was tested in real environment

Success Story - Cargill

* Observations:

- Ambitious first projects do not necessarily mean failure

* Adequate training and assistance

* Discipline

- High percentage of qualified consultants

- More ambitious projects mean more stress, less of a learning lab environment

Failure Patterns

* Unbuildable Project

- Too ambitious

- Requirements not clearly defined

* Non-skilled developers

* Users left out of loop

* Analysis Paralysis

* Prototype not scaleable

* Inadequate Training and Technical Support

Organizational Impacts

* Traditional Roles

- CIO

- Director

- Project Manager

- Lead Programmer / Analyst

- Programmer / Analyst

* Characteristics

- Lots of hierarchy

- Super specialization at technical levels

- Specialization is rewarded

Organizational Changes

* Flatter Organization

* People take on multiple roles

* Rewards based on productivity

* Commitment to Re-training

New Organizational Roles

* Object Architect

* Repository Manager

* Business Analyst

* Application Builder

* Visual Designer

* Database Designer

* Object Designer

* Consultant / Mentor

* Framework Designer

* Component Designer

Management Challenges

* Provide the Vision

* Manage the Transition

* Redefine how work is rewarded

- Speed of application delivery

- End User Satisfaction

- Creation of reusable components for next project(s)

Training

* Can not expect people to re-tool with a few weeks of training

* Strategic use of on-site mentoring

* Migration to internal mentoring

Where to go from Here?

* The Road Map to Object Technology Adoption - 1 day course

* Management Path

- Determine organization needs for OT

- Begin Organization Phase

- Identify Consultant

* Technical Contributor path

- Skill assessment

- Begin Training

Conclusion

* Benefits are real

* Start with your best people

* Get assistance early in the process

* Begin with smaller, well-bounded projects

Some Object Myths

* Objects = Reuse

* Objects = Well-engineered systems

* Objects = Reduced development time

* Objects = Seamless transition from analysis to design to construction

Sandra Smith (sandra@digitalk.com)

Regional Sales Manager

DIGITALK, INC.

333 West Wacker Drive, Suite 700

Chicago, IL 60606

Tel (312) 444-2065 Fax (312) 641-3096

Previous Page...