Kauri Vision

Intro

This document lists, describes and argues the basic insights and principles that drive the decisions in this project.

It is explicitly meant to trigger some like-dislike emotions in order for people to either resonate, find motivation and participate or else refute, classify and move on.

For a full list of features (which we think should have a lesser 'binding' power to the project) you should read the (unfinished) feature list.

Scope: Web Application Development

This project is about Web Application Development. Kauri aims to bring a solution to everybody, every role involved in a project that involves web application development. If your needs do not include developing an application with a web interface, then Kauri is probably not for you.

Holistic approach

To everybody: "Welcome!". 

The term 'holistic' refers to the believe that certain aspects of a complex matter (the 'whole' , e.g. project) cannot be captured or explained by only looking at (or masking the sum off) the different composing parts.

All Players

Web Application Projects involve quite a number of different profiles, experts and stakeholders, and often each of those have a fragmented view on the project's goals and deliverables and are witness to only limited parts of the team communication.

Sure enough given the mix of people, their schedules and priorities, there are quite a number of aspects of the project's management that naturally require some out-of-band (or -role) communication ("looking over the cubicle wall") and organization supporting tools (issue trackers, mailing lists, status reports, wiki's, and whatyouhave) but the point we want to make here is that, often times, there is just no single "project source/artefact repository" available which is the unifying and final source where the work of all project team members is living and growing.

This is often a consequence of a chained way of working where the work result of one actor is nothing more then input, a basis of rehashing and re-organizing for the next actor involved.  In the end this leads to confusing communication, wrong expectations, work being redone, longer roundtrip times and frustration.

The archetypical solution to this situation is to build a central system with a set of established contracts declaring the "Separation of Concerns"  (SoC).  While obviously correct in theory the practice of these solutions often seems to be foregone at the actual project level: a practical CoS-style is adopted, a Collaboration of Specialists:

• Fitting the actual set of individuals in the team (and not some predefined set of theoretically possible "roles", leading to 80% of those roles being played by  20% of the team.)
• Keeping together split responsibilities in single locations (rather then hiding the different aspects of the solution in N+ different files which you have to open all anyway to see what is going on.)
• Naturally keeping the communication channel open that continuously allow to fine-tune the inter-responsibility-contracts by pushing through both implementation and feature driven changes, broken tests, new interpretations, etc etc.

This is about more then just making all members check-in check-out from the same code repository. This is about making sure that their respective deliverables build up the actual working web site, service or interactive experience, and that they build up from the work of the other project actors. It assumes a flexible run-time that can host and process the various developed resources that together make up the actual project.

All Steps in the process.

Software projects tend to mature through some different steps on their way from inception (over analysis, design, prototyping, rethinking, testing, profiling and implementation) to completion. At each of these stages various people will be looking into what is already there, interpret what is still needed, comment on existing parts, and suggest or apply the needed changes to get to the desired end result. 

During this process, parts of work are completed as previous samples, place-holders, stubs or mocks are replaced by actual running code, introducing interactivity in the project.  By enabling this gradual completion of the complete project the mentioned run-time environment can ensure the complete development team keeps flocking together around a growing shared system of runnable code.

All Versions

This very same flow of the "growth and maturity" cycle has to pass across the boundaries of public releases of the web interaction layer.  Not only must there be a priori thoughts of defect resolution and maintenance, as new releases are bound to emerge there is also need  for controlled upgrades and / or backwards compatibility.

New versions should able to be actively developed in parallel, while different parts of the system can keep relying on existing solutions.

All Tiers

The pendulum of opinionated web application development has been favouring for a while either the browser, or the server side as the most prominent, logical, stable, future safe or trustworthy environment to host the bulk of the solution logic. 

Being resilient to the next swing of that pendulum nicely aligns with our earlier suggestion that the various web aspect experts should be happily collaborating on the project. Allowing each of those expert domains to directly contribute to the end solution should naturally leverage the natural benefits of the various platforms in the mix. Kauri wants to provide foundations for both the browser-, and the server-side, which nicely align and integrate with each other, as none of both platforms allow you to build the entire solution.

The development process

The only aspects of the web project we want to cater for are the ones related to the actual development (production). Reporting, planning and management aspects are not included.

We are thus in search of a 'system' (mix of platform, framework, libraries, guidenlines and tools, even some methodology) that brings practical answers to the common development use cases in web projects.

The common properties of these development use cases are:

• That they can happen in any order and iteratively.
• That they require short round-trip cycles favouring the continuous operation of a living development system (possibly through stubs, mocks and/or scripted prototypes), instead of detail-level completeness of each part. We want components and iterations, not waterfalls.
• That inputs, changes or enhancement requests to the development activities can come from various sides.
• That teams will start from a framework of conventions, standard approaches and sensible defaults. Leaving advanced cases and gradually customization optional.

The expected items making up the system are foreseen to be:

• a flexible and smart runtime environment environment (both in the browser as well as on the server),
• in other cases generic strategies,
• recommended conventions.
• pure development methodology scenario's or
• guides for using 3rd party tools. 
• Where needed own, specific tools and or management interfaces will be added to the mix.

Modularity 

After advocating the holistic approach it is time to give some reductionism a place as well. The mentioned holistic drive primarily wants to force collaboration between all members of the multi-disciplinary project team, and make sure each of their deliverables can be 'activated' in the system as directly as possible.

Practical experience with large and complex projects however learns that reducing the overall complexity in smaller chunks is a great strategy for keeping those projects conceivable and manageable.  Each chunk will typically have his set of experts working on them according to predefined interfaces between them.

Modules and components are often cited as a desired architectural means to achieve reuse.  In practice however we believe such advanced reuse is less important (nice if ever achieved, but in the fast moving web space seldom witnessed) then the more immediate gains of reduced complexity, gained consistency, and higher adaptability (needing to change certain things only once).  The primary focus for building modules is to make them usable, if done well reuse should follow.

These web modules in our vision are self-contained, separately released bundles that declare available services and (static) resources.  As such they will have a common natural interface upon which other modules can rely.  Some management (or injection) of dependencies between them will be required.  These dependencies should be expressed in a web-friendly or web-natural manner that allows a high degree of open networking flexibility.  Things we think about in this respect:

• Routing and filtering of requests as well as post-processing of responses (representations) like aggregating, templating, pipelining
  will allow to flexibly wire up the different modules into the application of choice.
• It should not matter conceptually if the services offered by these modules are hosted together, or spread over the network.

Looking at the web as one big system of many very different, loosely coupled but nicely (well, mostly or at least possibly) integrating services and systems, we find another reason for giving modularity a place.  The design option of choice for big IT integration projects is not to redo and centrally combine all aspects, but rather to loosely couple, and only to foresee a unified interaction mechanism.  This allows diversity and specialization, and even applauds the inherent autonomy of different systems at the cost of some extra runtime checks and lookups. 

In other words: the reality of the web, and the future of complex and large scale IT systems tell us to foresee a (web inspired) mechanism for different modules to call upon each other.  Thus various information pieces can consolidate into a unified view by aggregating, combining, filtering (and/or temporarily or permanently just reporting on missing past dependencies) resources from different modules.

Resource Orientation

The main approach we see to that flexible web-aware wiring is ensuring a web focussed strategy from the ground up. The way the Resource Orientation Architecture (term coined in O'Reilly's Restful Web Services) describes resources that are represented, located, named, addressed, and managed through a uniform interface is largely the direction we're going to. Being the 'seed of the Web' we think it should be 'grain of web-based project development' as well.

As some extra argumentation, we find this resource orientation matches very well

• The recent uptake in formal thinking about this (As witnessed from emerging rest based projects, published APIs, an upcoming Java Specification Requests, books, ...)
• The recent gained comfort (and expectations) in extensively using the browser platform as a base for RIA applications
• The old and wise advise to properly manage the URI space.
• Scalability and cacheability requirements for large scale systems.
• A road to applications exposing a better logic and content blending.

This is what the Kauri Vision is about: better tooling for better webapps.