This is Part I of a series that I will be doing on factoring your software architecture for development agility, software performance, and total cost of ownership (TCO).

When object oriented programming first arrived on the scene (25 years ago!), it delivered important concepts: encapsulation, polymorphism, and inheritance. These concepts were designed to help the developer factor code. Proper factoring reduces complexity, redundancy and cohesion. One of the most powerful factoring techniques in programming is grouping for reuse.  Functions, Objects, and Aspects are all code groupings that organize an area of concern for reuse.

Code reuse and other factoring techniques tend toward greater simplicity and development agility. These characteristics have an important and positive impact on cost and revenue. There is no doubt that software development can be an expensive undertaking and at the end of the day it’s always about the economics.

As we have observed, programming languages have been evolving to help manage complexity and make software development more efficient and effective.  As computing power continues to improve, platforms are also evolving to improve development agility.  For example JAVA introduced the JVM and the concept of “write once run anywhere.”  It’s clear that the JAVA platform (as opposed to the JAVA language) provides clear agility over languages compiled to specific machine architectures because it removes the dependence on specific machine architectures by introducing an abstraction; the JVM. It has greatly simplified building, packaging and the distribution of software.

Today scripting languages are mainstream.  Scripting languages are generally loosely typed and are interpreted rather than compiled. There are debates between what might be termed the “systems level programming languages” and “scripting languages.”  Some in the traditional camp cite that scripting languages lack rigor, and claim that it won’t perform when compared to their compiled counterparts.  Those in the scripting community point to “extra work for little value” and complex deployment environments as the other side of the coin.  The communities around PHP, Ruby, Python, PERL, Groovy and others boast impressive development agility characteristics over JAVA, C++, etc.

It’s unlikely that there is anything inherent in the languages available today that drastically change the agility characteristics of development in those languages.  Most of the mainstream languages have similar concepts and differ in terms of syntax.  While some expressions may be quicker in one language over another, it’s unlikely that any of the mainstream language’s syntax will produce agility characteristics that are orders of magnitude above and beyond the others. That is to say, it is not the “PHP” in “PHP” or the “Ruby” in “Ruby on Rails” that makes them faster to develop in. It’s platform and architecture that accounts for the difference.  PHP, Ruby and many other examples are interpreted rather than compiled and this means that when a change must be made to a program there is no need for a recompile and no need for a restart.  Just change the code and (in the case of the web) hit refresh.  In the same way JAVA cleaved an entire effort out of the development process (building for individual architectures), scripting languages have cleaved a massive time sync off the hands of developers by making it easy to modify code “on-the-fly.”   I believe that scripting and compiled languages are not at odds but rather they are complimentary.

The strong typing, static analysis and offline assembly of byte code makes perfect sense for framework or systems oriented code.  This code is not likely to change much in the course of an implementation but is executed frequently. Framework code often defines the performance profiles of a system.  You always want to optimize when possible.  Where there is no absolute requirement for interpretation and no strong value proposition it should be avoided.  That is to say favor compilation over interpretation where interpretation does not deliver significant value.  Don’t make the machine do the same work twice when it can be avoided.

Application level code (as opposed to framework code) changes often.  Developers benefit from the ability to easily write and run code without having to restart servers and perform compilations and deployments.  Application code has a lifecycle and release cycle that is much different from infrastructural / framework code.  This becomes more and more apparent as the framework matures and changes less and less often.  They are two different types of code with two different lifecycles.  Businesses don’t want to spend more time on framework than is necessary.  The value is in the applications and this is where agility matters most.

The optimal approach doesn’t have to be one or the other (although in some cases it is.)  Each platform plays best to a different set of concerns.  In software, a common approach for tackling separation of concerns is called layering.  It is possible to layer a system by using a traditional, compiler based language and platform (such as JAVA) for infrastructure needs while leveraging scripting languages and template technologies (such as PHP, Ruby, Groovy and so on) for the application layer.  By doing so, you combine the success characteristics of both platforms: compensating for weaknesses while playing to strengths. To understand the power and success of this approach, one needs to look no further than Excel; a truly killer application.  Excel is a framework.  You bring the application to it when you build your spreadsheet.  Excel’s (a compiled, c++ based application) power is opened full bore with the VBA scripting environment.

We also see this approach taking hold in the web space with packages like Bean shell, groovy, JRuby, Quercus PHP and so on.  At a recent community conference Alfresco, an open source enterprise content management platform demonstrated SURF, a java based framework that enables developers to code applications in server side Javascript.  Alfresco used the SURF platform to create its new Share application (a Share Point alternative.)  They are moving away from developing in pure JAVA because it just doesn’t provide the agility they need to compete at “internet speed”. Instead, they will continue to build their core repository and framework in JAVA but applications will be built based on SURFs support for Javascript and templates.  It’s powerful and fast as a development platform.  The productivity Alfresco has demonstrated in the last year is truly impressive and a testament to layering the two types of development platforms.  Use the right tool for the job and it will get it done better and faster every time.

I’d like to point out one more important outcome of layering your development platform. In doing so you can greatly reduce the learning curve that one must overcome before one can develop for the system.  A relative few people know how to program in JAVA.  However a great many more people have at least some experience programming in Javascript and even more have experience with PHP.  Why?  That’s simple. Javascript is common on web pages. PHP is offered by almost every ISP on the planet and it has a huge online community from which one can find code examples.  When you layer your system you get all the technical benefits of JAVA on the back end with all the benefits of easy to develop code on the front end (the application) in a way that is open to a very wide range of developers; for example: The core framework written in JAVA and the application consuming that frame-work written in PHP (Quercus PHP is an Open Source, JAVA based implementation of PHP5).

PHP developers tend to be much more available and affordable than JAVA programmers. It’s simple economics.

Today I am back in Boston after spending most of the week in Washington DC. I was there for the Alfresco Community Conference and also to spend some time at Rivet Logic’s new headquarters. We have a lot more room for our team in our new digs. Every time I have a chance to spend time with the group in Reston I am reminded of what an awesome team Rivet Logic has put together and why joining this team was such an easy decision.

The DC Conference was absolutely awesome. I left DC with the same excitement I had for Alfresco the first day I read about it on the web back in early 2005. This coming release is a Landmark release for Alfresco and a springboard for really big things in the future.

Last year Alfresco gave us Web Scripts. Web Scripts was raw functionality / capability for binding web-based functionality hosted in the repository to a parameterized, ReSTful URL. Web Scripts allowed Alfresco to easily integrate with other platforms, participate in mash-ups and to some extent get around the issues with the traditional alfresco web client (it’s much slower to develop for and a bit “click” intensive.) Web Scripts by it’s very nature is AJAX friendly which leads to better, more rich user experience and the javascript / freemarker construction makes building Web Scripts a whole lot easier than writing, compiling and deploying heavy Java code.

This year Alfresco gave us:

• A better core repository
• SURF
• Alfresco Share
• A peek at SURF Development Studio
• CMIS

It’s clear that without the foundational work of Web Scripts and the capabilities in the WCM product the items above would not have come to pass in a single year. Web Scripts has enabled an explosion of capability. Last years release of Web Scripts may have seemed like a powerful but merely additional capability but it laid the foundation for a huge growth explosion. The game board was set up with last year’s release and it is evident with 3.x that the game has changed.

As Alfresco’s application architecture is refactored they are also able to refactor their team a bit and more cleanly dedicate resources to specific areas of the architecture. We now have a dedicated team of strong developers with a focus on repository scalability and stability. This week we were told we can expect better performance, scalability in both the DM and WCM repositories. We also heard that harmonizing the APIs and capabilities for these repositories is a goal and is underway. Alfresco has also added a new remote interface to the repository that allows Microsoft Office to use the Alfresco repository as if it were a Share Point server. Something good just got better. I like the direction the engineering is heading by cleanly separating the repository from the applications that work on top of it. I also like what I have heard about the focus on key areas like performance and scalability. New features are always important but are a distant second to improved performance and scalability of something as core and foundational as the repository and its content services.

SURF is an application platform for aggregating and delivering Web Scripts (and other components.) SURF is an MVC for site / application composition. Alfresco has taken Webscripts, templating, and URL addressability and parameterization capabilities out of the core repository, combined them with a set of new capabilities and re-organized them in a entirely separate framework. In essence SURF is entirely independent of the Alfresco Repository. The key here is that while SURF is entirely separate, creating Alfresco client capabilities in SURF is a snap.

Alfresco Share is a new application that Alfresco has developed, which, for many people will eliminate the need to use the traditional Alfresco web client for anything other than repository administration. Share is a collaboration platform similar to something one might expect from Share Point but with much more Enterprise 2.0 and social features. Share is really impressive and it demonstrates what can be built with SURF and how quickly and easily one can build it. Share was developed in less than a year but has features and capabilities of other systems that have been under development for years. Best of all, Share will continue to get better at a similar rate and because it is so easy to write new components with Web Scripts the community can contribute and accelerate this growth.

Development Studio is a SURF based application that integrates with Alfresco WCM, the Alfresco Network and your SURF application to provide you with a visual (WYSIWYG / drag and drop / edit in line) environment for developing SURF applications. I truly believe that Alfresco WCM is an awesome platform with advanced features and capabilities not found anywhere else in Open Source and in some cases even in the world of the proprietary giants. WCM is a new platform with groundbreaking capabilities but without a something like SURF or the Development Studio to demonstrate these capabilities, it was hard for customers to recognize the value sitting right in-front of them. Early on in WCM, Rivet Logic had developed similar capability to what you see in SURF for the exact same reason. SURF and the Development Studio help to round out the Alfresco offering and will really help to highlight the unique and powerful value in Alfresco WCM.

CMIS (Content Management Interoperability Standard) is a new standard for ECM platform interoperability. Today it is in DRAFT status with OASIS but according to John Newton, CTO of Alfresco there is a strong probability of its adoption with the backing of the like of Microsoft, Documentum, Open Text, Alfresco and several other key players. CMIS supports both Web Service and REST based protocal bindings making it very easy to integrate in to an existing platforms. Alfresco’s REST implementation provides nearly full coverage of the specification. Web Scripts played an important role in the lightning-fast turn-around time for this implementation. Again we see the foundational work of Web Scripts delivered last year providing big results less than a year later. CMIS will allow developers to write repository agnostic applications that will work against any repository which supports CMIS including Alfresco. CMIS also specifies a SQL like query language. Unlike previously proposed standards that pushed XQUERY and XPATH, CMIS is adopting a well understood paradigm which I believe will only encourage its adoption.

It was a fantastic week and an exciting conference. If you have not looked at Alfresco lately it is definitely time to take another look. This is truly an exciting release for this product! I really enjoyed the opportunity to see everyone in the community, Alfresco, and at Rivet Logic HQ.

Alfresco WCM (Web Content Management) has traditionally focused on the core “management” aspects of web content.  This focus has facilitated the open source development of world-class WCM management capabilities. The versioning, workflow, preview and deployment capabilities offered by Alfresco WCM are found nowhere else in the open source space. Similar features found in the proprietary space cost an order of magnitude more than the Enterprise licensing (for services and support) offered by Alfresco.

Today, choice of delivery platform is left completely open the consumer.  The Alfresco WCM platform makes very few assumptions about the type of website is being managed. It possible to manage static sites, .Net sites, PHP based sites, Java based sites, Ruby sites and so on.  While this choice is important, many customers would like a complete solution provided by a single vendor that covers both management and delivery of web content.  Furthermore, because today the product is management focused it can be difficult for customers in the evaluation phase to quickly download and identify the true value inside WCM without a lot of upfront work.

Many websites today require dynamic and personalized components.  The more dynamic the site is, the more complex the solution tends to be.  Typically costs and the required technical skills needed to maintain the site track closely with the level of complexity. Businesses today continue to look for easy to deploy, simple to maintain WCM solutions that minimize the technical skills needed to produce and manage sites. Large, full-time development staffing is expensive, difficult to hire for, and hard to maintain.  The more work that exists which requires a strong development skill set, the less users are enabled to care for their own needs and the greater the constraint on throughput and agility. Simplicity and agility are key success factors on the Internet today.

Alfresco, having established a strong foundation in core web content management capabilities has now begun to focus efforts on making it very easy to construct and deliver sophisticated, web 2.0 dynamic websites.  Alfresco hopes its new platform named Surf will enable knowledge workers to manage enterprise class, dynamic websites with little or no deep technical skills required.

What is Surf?  Surf is an application framework for developing and delivering dynamic websites. Surf leverages existing Alfresco technologies including Alfresco templating and Webscripts.

Surf has been designed from the ground up to leverage web-enabled tooling that exposes powerful capability such as inline editing, drag-and-drop positioning of content, point-and-click template selection and so forth.  These tools make it possible for users with very limited technical training to manage significantly sophisticated dynamic websites.

Under the hood is a powerful engine for aggregation of content and application behavior.  The Surf architecture shows a deep appreciation for the Web 2.0 inspired architecture and web application mash-ups.   It’s important to point out that while tools exist to reduce the need for technical skills, the platform does not eliminate or discourage access to its internals for those who need it.

Surf and the tools designed to help manage Surf based websites represent an exciting and powerful next generation WCM platform that covers both core management aspects and delivery capabilities.   Alfresco continues to bring enterprise class features to the open source ecosystem, improving on battle tested concepts with groundbreaking innovation, modern technologies and leading development approaches.