Business Considerations

Last Updated September 17, 1999 - Jack Harich - Go Back

---

A Call to Refocus

Probably our top risk is UHR fails to be adopted much at all by businesses.

Another top current risk is being way too technically focused, as engineers are prone to be. :-)

We need to learn from failure and let technical decisions be driven by business considerations. This way we can deliver "more appropriate usefulness". We're doing fine - We just want to resolve risks.

---

Failure Analysis

UHR failed to be adopted at CDC, Delta and REALM. Why?

CDC - John Fitzpatrick attended many JSL and AJUG meetings regularly. He's a manager of several developers and IT services. He saw Jack and UHR as bringing ATSDR, a 400 person division of CDC, into modern software practices. He invited Jack in to rewrite a small Clipper database app using Java and UHR, training Tom Rouse in the process to take over and then convert many more apps.

It didn't take. Tom was a very procedural guy, totally new to OO and Java. It was way to much of a leap for him, and as Tom's learning started to fail Tom and John talked if over, and Tom found a new job. That took 4 months in the Summer of 97, with the app unfinished. In the Fall Jack completed the first BA, which was previously a simple framework. On February 2, 1998 Jack came back to CDC to redo the app in the BA with Julius as the developer to be trained. Things went much better, though Julius wasn't available till late in the project. The "ATSDR Awards App" was completed, deployed, and John and his boss Mike were very pleased. They foresaw using the BA a lot.

But the BA proved hard to understand, impossible to customize by Julius, and the database/GUI framework of parts proved difficult for Julius to grow. John kept Jack up to date on all this. Finally as a solution John went with IBM's Visual Age. UHR is no longer being used for new work, and the original Award app remains the only one every deployed there. But John is still pleased with Jack's contributions to CDC.

Another problem is there was no part or framework inventory at this point. Most of Jack's time went into part and framework developement. The BA held up pretty well, requiring only minor imrovement.

Delta - Darryl Pentz, JSL list member and occasional meeting attendee, invited Jack in to help his department of 4 do a project "the right way" in the Fall of 98. His needs were in process, OO and frameworks. Jack showed his group the BA. They were impressed, but Darryl was prudent. The BA was simply way too big, undocumented and immature for Delta to support in widespread use. Besides, it was too much for the small project - A dozen or two HTML pages managed by Servlets, working with several back end data sources.

So, instead of the BA, Jack designed a simple framework that supported layers and part lookup. That's all they needed. They were exposed to the Mini Process, OO Analysis and Design, Jack's personal development style (which they commented on greatly), and a simple framework. They were please with the results.

REALM - This was more complex. :-) Jack came to REALM in Fall of 98 for Java and OO training, by building a Java fat client for their server. He worked elbow to elbow with Larry Gee for 2 months on this, and then with Mike Panetta and Joshua. Jack noticed it would be a good fit for the BA, asked Larry if it was okay, and built the client with the BA. Jack's style was to design an area, do the initial framework and implementation, and then others would provide the many worker parts needed. This worked very well, the project zoomed along, and REALM was very pleased with the result. They saw the project as a major success. Management estimated UHR had improved productivity on the project by a factor of 2 to 4.

A delayed reaction occured. First Michael Ivey gradually started liking Java and UHR, and then he personally did a client screen using it. As he said later, "I implemented an entire screen in 2 hours ". This and a cumulation of other experiences blew him away, and as he put it he had an "ephipany" about UHR and became a UHR champion. Gradually Britt became a champion too, and then Stacy. Soon REALM itself was sponsoring Jack's full time work on UHR and his assistence in using it at REALM. All was peaches and roses.

So REALM said let's grow some UHR experts, and in early 99 hired Champion1 and later Champion2 to do UHR product work while Jack just developed UHR. The idea was Champion1 would become REALM's first in house UHR expert and champion. Well, that never happened. It appears that Champion1 could never understand the BA, never mastered how to use it, strongly disliked it and UHR - all for not well understood reasons. As time went by, Michael, Britt and Stacy focused on other areas, leaving Champion1 as REALM's main UHR champion - which he was on the surface, but below was not. This led to zero addtional use of UHR on new projects, and the slow collapse of UHR at REALM. Eventually REALM woke up one day in September 99, noticed UHR was costing lots but delivering zero, and pulled the plug on further UHR investment. If UHR had been delivering value, REALM would still be sponsoring it. In retrospect, if Champion1 had been a different person such as Champion2, UHR probably would have thrived at REALM. Sigh....

Exactly why did these failures occur? - IMHO they all fall under the rubric of Technology Transfer. UHR simply failed the Evaluation or Technology Transfer step at the business level. After all, when Jack was on a UHR project it succeeded, but when he wasn't, they failed.

On the good news side, UHR is rapidly maturing due to these uses and Steve Alexander joining Jack in efforts to develope it. Our bumps and grids, detractors and believers, successess and failures, are all normal for early in the life cycle of novel new technologies.

---

Technology Transfer

Technology Transfer is the act of transferring the successful use of technology from one holder to another. Common cases are from academia to industry, or from vendor to customer. The more novel the technology, the greater the risk. Of course, sometimes the greater the risk the greater the opportunity.

On the consumer's side, it takes time and significant investment. Preparation is required before the transfer begins, serious training is required, a ramp up phase is needed, and top quality people are mandatory. Leaving these out or skimping on them increases risk of transfer failure. Some consumers need education on how to best approach Technology Transfer.

On the producer's side, ease-of-transfer must be designed in from the start, just like quality. Evaluation must be easy and adoption look low risk. In particular, a complex technology must be able to be digested in little bitty bites, and be flexible enough to meet different needs. In the case of mega frameworks, they must not be a big inflexible hard-to-use monolithic monster, which is what the current BA is in the eyes of users, along with the IBM San Francisco framework and many IDEs like Visual Age, Silver Stream, JBuilder and Visual Cafe.

---

Core Variations

To ensure easy Technology Transfer a business needs to absorb UHR gradually and appropriately. Hence we must design the core for easy transfer. The guiding motto is "keep the core simple and flexible". Here's how easy transfer could happen:

1. They can start with a minimal core, no DK or Messages. It just behaves like a bag of parts. This can be done with less than a dozen classes and interfaces.

2. Then they can aggregate the parts, such as in layers.

3. Then if they get a lot of parts, they can highly organize them into a tree.

4. Then for reuse they can introduce DK.

5. Then for loose coupling they can introduce Messages, and they have the full core.

6. Then for serious systems they can use optional generic frameworks for things like transactions, problem escalation, live part updates, and system migration for failover. There are also optional core parts such as for use of reflection in Container DK.

This allows a developer or group to start at the level they are comfortable with, and then scale up as they become ready. Since they can start a very small, simple level, the risk factor is small. Since they can match the solution to the problem so easily, it all looks quickly productive and low risk.

The minimal core would support cases 1, 2 and 3. By then they would be clamoring for DK, which is much simpler than Messages, more familiar, and more necessary. The Message variation must follow the DK variation, because DK is the best way to hookup lots of Messages. The optional frameworks depend on the full core. These variations are:

Other variations will appear as time goes by. The important thing is to allow a developer to use just as much of UHR as they need. It's like sprinkling on only as much hot sauce as you want, and not the whole bottle every time! :-)

How would this have affected results at CDC, Delta and REALM?

CDC - Tom, who didn't know Java or OO, could have started with the Minimal Core since his app was so small. Then as it grew to several screens and tables, he could have upgraded to the DK Core. He never needed Messages. All this would have been a much easier learning curve.

Delta - All they wanted was a layered framework of parts. The Minimal Core does this beautifully. As time passed, they would have the option to upgrade to the DK Core, which I suspect they would have done a few months later.

REALM - Late in the game, the immediate problem with a key project was the BA didn't run in the micro Java environment. The Minimal Core would. Another problem was Champion1's unfounded objections to using DK and Messages. The Minimal Core avoids these. Another problem was Champion1's shaking a finger at no regression test. Well, the Minimal Core is too small to need one, or we could have written one in a few days. Champion1 was pointing out some real problems, and manufacturing others. Probably Champion1 would have found more reasons not to use UHR, but it is difficult to satisfy such "problem customers".

How would this affect the Open Source movement? We will let you guess....

---

UHR Use Model

Picture the average Open Source developer evaluating UHR. Will it solve their immediate problems? It will if it's simple, flexible and has proof it works. Simplicity is provided by the small core variaions size. Flexibility is provided by multiple core variations. Proof is provided by Sample Systems and references. As discussed above, our referernces are not strong yet. We can grow them by in house use and one new customer per Jack, Steve and Helen. ??? :-)

The idea is not to convince businesses, but individual developers of the usefulness of UHR. That's where mindshare starts, and is where contributions back to Open Source happen. Thus our Educational Materials and entire business model needs to be focused toward developers, not businesses.

An interesting model is the UHR Consultant. They walk in the door with a bagful of reusables. This lets them do dynamite work for their clients. Their clients rave about their work, the consultants improve UHR as they use it, and it's a win win for all. This is a great feedback loop on reuse because the consultants will carry parts from one business to another, giving reuse the acid test.

---

As Steve pointed out, what about the Domain Expert, who doesn't even need to code if the Visual Tools are mature? Whoops, that's another user type, which we forgot to mention in this document.