Christian Cryder's Take on the BA

March 7, 1999 - Christian Cryder - Go Back

---

Happy Jack wrote:

> What is your take on the BA? What does it do right that makes you so
> confident it's the horse to ride off into the sunset? What could it do
> even better?

Well, when Jack asks you have to answer, so I'll give it a shot... (you can
decide how close it lines up with your own views).

Let's start simply: where is everyone in the industry going? Components! Sun
has EJB, Microsoft hase DCOM...everyone and their brother has been preaching
the value of components for years. And its not hard to see that there's a
lot of sense behind this approach: if we can make good components, software
development should be as simple as tying the pieces together.

Unfortunately, in spite of all this component-itis, the dev process is still
very laborious and labor-intensive. If components are the answer, the real
question becomes, how come we're experiencing such minor productivity gains?
Why does Moore's law apply to hardware but not to software? Why do we still
find ourselves saying "there's got to be a better way"? 

I think the answer is simple...components are not the answer in and of
themselves. Why not? What's missing in the equation?  What is making our
components non-reusable? The answer almost always has to do with business
logic. We find a component which almost does what we want, but not quite. So
we are forced to customize it (read=we add application specific code to it)
to make it do what we need. And voila! We've solved our immediate need
(getting the application to run) but we've shot ourselves in the long term
foot (reusability), because we've just created another non-reusable part!

Why is it non-reusable? Because we added the application specific logic to
it. The problem is, good components need to be as simple and as focused as
possible. They need to do one thing and do it well. This is demonstrated by
the places where we are succeeding with components: GUI libraries (like
Swing) are greatly improving the UI side of things; data components (like
JDBC) are dramatically expanding the portability/reuse on the database side
of things. What do they have in common? They're systems comprised of very
simple parts which do very specific tasks and no more.

Simplicity is the key for componentization to succeed. The problem is
business logic/requirements are typically very complex...what we need is a
way to strip the business logic out of the components and store them
separately; then, we _should_ be able to re-use our underlying components
more readily, and thus achieve higher re-use. As Jack likes to say, its
separating the "what to do" from the "how to do it".

As far as I know, Jack's approach is the only one I've seen which is taking
this angle.

The result is profound; we end up with very simple "Parts" which do very
specific tasks. It is easy to write a bug-free component if the component's
functionality is simple enough; the problem is keeping the component from
doing to much! (Stop and think about that for a moment: how do we typically
design? We start simple and then come back and start _adding_ all kinds of
functionality, bugs increase, development time increases, and our
productivity plummets...this is very profound once you recognize it). If all
we have to do is code for very simple tasks, we can achieve a much higher
quality factor and thus greater reuse. What we need is a way to design very
simple components and then allow them to easily communicate with one another
without necessarily knowing anything about one another.

The BA simply provides a domain-neutral infrastructure for allowing the
Parts to talk with each other without knowing anything about the parts
they're talking to. Declarative Knowledge (DK) is the means to tell these
simple parts what you want to do.

I was really skeptical of DK at first; When you want to tell a part what to
do, you need both nouns and verbs...the nouns are easy: you store those as
parameters. But what about the verbs? The lightbulb went on when I realized
that the verbs are Parts themselves! In other words, take some parameters
(nouns) pass them to a Part, and voila! You have a verb! Put enough of these
together and you can build a sentence, a paragraph, a chapter, even a book.

The key really lies (and this is where most component based approaches fail)
in making the Parts simple enough; more complex verbs are created by stringing
together a lot of smaller verb/noun combinations. In fact, if you think
about it, there are some very interesting parallels between a language and
its ability to express complex ideas... (this could be a very fruitful
discussion in and of itself).

So...to wrap this up and bring it home: I've come to many of these
conclusions in my own framework development efforts as I find my frameworks
becoming more and more generic...the ability to combine a lot of very
generic pieces in different ways is what provides true flexiblity and
expressiveness. Needless to say, when I examine Jack's BA stuff, I don't
really see anything that _can't_ be expressed through either a part or a
parameter. The key is really in creating a lot of simple enough parts which
don't do too much...this is very difficult and will simply take time.

Ultimately, the question I asked myself was: do I continue to go down my own
development path (in which case I may end up recovering a lot of ground
Jack's already dealt with) or do I transition into his framework, and bring
what I've already dealt with along.  Given the fact that most of the
problems I see with the BA are related to immaturity, rather than
architectural issues, the decision wasn't too difficult, especially as I got
to know some of the other folks working on the BA.

So now, we still have a lot of work to do (I see real maturity and adoption
occuring 3-5 years out), but like I said in earlier emails, I really think
the direction is the right one, so here I am :-) 

The immediate needs for the BA include:

1. Making sure we get the MicroKernel really right the first time, since
everything hinges around this. The implementations can improve iteratively,
but we've got to get the interfaces right on the first or second pass. 

2. After this, we need to really improve the documentation and training
materials in order to make the whole BA thing approachable for those who are
new to it. 

3. Next we also need to create a good tool for telling the parts what to do
(this is the Param Editor). 

4. Finally we need to start creating really good useful Parts. This will be
by far the most difficult and time consuming task, and what is really needed
to make it happen is developer effort...If I intend to contribute I need to
be able to really focus, and so I decided that joining the team at REALM was
probably the best means to achieve that goal.

That's a lot of stuff, and this was a long answer to a short question!
That'll probably serve as a reminder to be careful about asking my opinion
on something :-)

So...now I get to throw the question back to you and everyone else...what do
the rest of you think the BA does right (or wrong!)? What do you see as the
biggest needs? Your feedback at this stage in the game could prove
invaluable, so don't be shy!!!

Christian

(Hey! It finally _didn't_ rain today out here in Washington...cool!!!)
------------------------------------------------------------
Christian Cryder
Sr. Java Developer, Puget Sound Systems Group