Goals of Cernunnos

The central motivation for The Cernunnos Project can be expressed in one word: Effectiveness. Cernunnos allows IT professionals -- particularly Java engineers -- to be more effective.

More specifically:

• Cernunnos can help you deliver more software value in less time; and
• The solutions you implement with Cernunnos will require less maintenance after delivery

It's not about scalability, security, or usability -- though these are also admirable qualities in software. It is about reducing the cost of creating software value. This is the purpose of Cernunnos and the reason it was created. If these aims are achieved, The Cernunnos Project will be a success.

You Can't Get There From Here

The cost of custom software is high. Software engineers are well-compensated knowledge workers, and even small amounts of software value commonly take days of development using industry-normal methodologies. Software projects fail at an embarrassing rate, and countless potentially useful projects are never begun because the high costs outweigh expected benefits.

The Java Platform, moreover, doesn't make this situation any better. To be sure, Java has many attractive qualities: platform independence, elegant support for Object Oriented Programming, platform maturity, and phenomenal industry acceptance (to name a few). But Java is not recognized as a platform for rapid development. Java source files typically contain a high ratio of "boilerplate" content, and Java APIs are notoriously obtuse.

Realities like these make it harder to create solutions in Java at a price that's worth paying. Think of it this way: each class, method, or line of code has a cost and, therefore, a conceptual "threshold of business value" it must meet to justify its existence. The more custom code you must write to implement a new solution, the less likely you are to do it. At some point the expected benefits don't justify the investment.

Implementing Solutions vs. Implementing Technologies

A solution is the answer to a problem or organizational need. Ultimately we are all interested in solutions: business owners, managers, even developers! But beneath the surface, software solutions are built from operations or behaviors.

And although solutions must target specific problems, software behaviors need not do so. Behaviors can be "agnostic" of -- and therefore unfettered by -- the problems they help to solve. They can, moreover, be grouped thematically into useful modules, projects, or technologies. These technologies are not themselves solutions. But when they are well constructed, they are the building blocks from which solutions can be constructed rapidly and reliably.

Imagine you were drawing up blueprints for a new home: would you begin by designing a door hinge, a roofing tile, or a nail? Of course not -- that would be a tremendous waste of resources. It would take a lot of extra effort to reinvent these components, it would be very expensive to have your custom specifications manufactured, and the finished product wouldn't be as good as what you could get at Home Depot. In mature industries -- e.g. construction, apparel, furniture, and even mechanical engineering -- we build high-level solutions from standardized low-level components.

Yet in the software industry we reinvent these sorts of low-level building blocks constantly. It's a bit of a pain to query a database using JDBC, and furthermore it's easy to make a mistake. But honestly how different are the needs of one JDBC query from the next? The SQL is different, and what we do with the results is different... but communicating the query to the database is no different in 90% of cases... except where it's not done properly.

Does this mean that we should only have one JDBC query implementation that we use in every case? Certainly not! But perhaps it means that every case doesn't require a brand new query implementation. Perhaps we could maintain a few query implementations that cover most cases.

There are plenty more examples in Java of tedious, low-level behaviors we reinvent frequently: XML parsing, XSL Transformations, database transactions, automated emails, etc. If we can provide an effective way to decouple these behaviors from where their inputs come from and what happens to their outputs, we will be able to stop reinventing them and simply reuse them.

Cernunnos is a Form Factor for Behavior

In essence, this is exactly what Cernunnos does: it provides a standard interface or "contract" for software behavior. Useful behaviors can be implemented against this contact, and then instrumented through a lightweight XML syntax. The outputs of one behavior quickly and easily become the inputs for the next.

Cernunnos is not different from software development -- it's a different way to practice software development. Behind the scenes, the code is the same as it ever was. The difference is that each behavior is no longer bound to the details of a specific problem, and the impact of this difference is that you don't have to keep reinventing the same behaviors every time you need to solve a new problem.