The Big Picture
LM Framework uses a software architecture in which web applications and services are designed and delivered as a series of generic building blocks, which we call micro-components. This is the first in a series of posts which together will describe the architecture, explain the rationale behind many of the design decisions, and point-out why we’re excited about its potential. The series will start off at a high level, and will become increasingly more detailed and implementation orientated. In this post we’ll introduce the Mixable Web - we’ll explain what it is, and how it could possibly influence the way we build and use internet software and services in the future.

The Mixable Web is simply an alternative way of viewing software and data, and is very general. As such, it applies both to how users interact with applications, and how applications themselves are constructed. It hinges on the notion of compatibility. The logic behind the Mixable Web is very straightforward: the more applications (or more precisely the components from which they are built) are compatible with each other, the richer the user experience, and the more power in the hands of the developer.

Size Really Does Matter
The image below shows a stylized component breakdown for an application. It’s not necessary at this stage to know what the application does, or what the components represent. The key point is that a high proportion of components are referenced more than once within the specification. This is what facilitates the underlying compatibility between the various parts of the application, and, as we’ll see in a moment, it will also enable us to create new applications by simply combining existing ones.

The skeptical reader is probably thinking “So what? There’s nothing new here”. And whilst it’s true that component re-use is an established practice in software engineering, it’s also rare to see the concept taken to such extremes (in LM, components can be as small as a single image, or a line of text). In future posts we’ll list some low-level advantages of the micro-component model (which are closely linked to the current limitations of both the browser, and of delivering a web application as a series of distinct web pages). But for the time being, we want to focus on the high-level issues concerning deep component compatibility - and the resulting benefits to both the user and the developer.

In the image below we can see what happens when two applications are combined. It can be seen the two stand-alone applications share many components. This is not a coincidence. The smaller and more general purpose the building blocks, the more likely they can be re-used in different contexts, which leads to a more granular compatibility both within and between applications. This also explains why the original multi-purpose Lego blocks are much more versatile than today’s highly-specific ones!

We’ll be seeing this image again in a later post where we talk about compression and latency - two key issues for web-hosted software (SaaS). There are many other reasons for being happy to see so many shared components in the new combined application. Setting aside the footprint issues mentioned above, here are some of them:

• Graphical consistency
  The combined application shouldn’t look like a patchwork quilt
• Behavioral consistency
  Clicking on the same button in different contexts has the same effect
• Customization consistency
  The developer (and in theory the user) can customize components.
• Data consistency
  It should be possible to share data between the two sub-applications
• Easier development
  Using existing components represents less work than creating new ones
• Less testing
  Existing components are more likely to be stable

The fourth point, data consistency, has major ramifications. One of the key differences between desktop and web applications is their relative levels of interconnectivity. Desktop applications are more like islands: information can travel between them, but the journey is often not easy. Web applications, on the other hand, frequently have data integration at their core - this a direct consequence of the web’s open and multi-point architecture. Much has been made of ‘mashups’, where data from diverse sources is presented on the same web page, but this still represents a mainly read-only situation. In the future, it will be possible not only to read, but also share, organize and integrate information from disparate sources, all from within the same application.

Application Ecosystems
Just about every web site connects to a some sort of database. Most of the time, the only way to access the database is via the website, although some services now make a distinction between the two (Twitter is a good example). The micro-component architecture allows data sources to be viewed as components themselves (each with its own access permissions). And since LM applications share so much low-level DNA, it will be possible to seamlessly integrate information from different sources within the same application. This means going beyond simply displaying the information on the screen, and transforms applications into something closer to mini-platforms - with the difference that they do not necessarily have to remain isolated. To return to a geographical analogy: an application can start off as a small island, which is then gradually integrated with other applications to form ever larger and more complex land masses: bigger islands, continents, and - why not? - even planets!

This potential for combining and re-combining functionality and data sources into ever richer (or more focused) applications is exciting. There are some pretty clear evolutionary analogies, which open-up the possibility of dense application ecosystems emerging. But let’s not get ahead of ourselves. To flesh-out these concepts, we’ll present two examples; one generic and one specific.

In the image below we can see three stand alone applications. For simplicity we have each application referencing only one data source, but there is no reason why they should not reference more. We then create a new application by combining the first two. The merged application now references two distinct data sources and effectively creates a (bi-directional) bridge between them. In the final example we combine the third stand alone application - effectively super-imposing the three sets of functionality and data access within one unified application.

Abstract examples are fine, but it’s quite hard to grasp what’s actually going on. So, in the image below we render the three applications more meaningful. We start off with a contact manager. It doesn’t do a great deal apart from allowing us to effectively organize and annotate (generic) contact information. Perhaps it includes modules (components) for communicating with our contacts: email, IM, etc. The second application is a customer relationship management (CRM) system. It’s a lot more specific than the contact manager, but is focused almost entirely on logging and measuring customer engagement. It’s not particularly good at organizing contacts or communicating with them, so it makes a lot of sense to merge the two applications. The operation is not necessarily painless, but owing to the fact that both applications are built from the same basic blocks, a lot of low-level compatibility issues are either eliminated or reduced. Finally, it also makes sense to plug-in the billing system. There’s not much point having a separate system which relies on the same underlying data (contacts). Hopefully, you’ll agree that the resulting application is more useful than the sum of its parts, and, assuming the three independent applications already existed, it will have taken less time to build than a brand-new application. Not many wheels were re-invented.

Perhaps this last example throws up more questions than it actually answers: how is the data merged? Is it actually merged, or is replicated across the three databases? If it’s the latter, does this not give rise to normalization and integrity issues? Can the three stand-alone applications continue to access their original data, or is the combined application incompatible with its ancestors’ data sources? All good questions. Our reply is that the architecture merely facilitates the integration, it doesn’t do it for you. It provides entities such as generic hierarchical data structures (which can contain any arbitrary field format- including references to other data structures). It provides techniques for combining and extending data definitions (which are separate from the data structures themselves). In other words, it provides very general tools (which will be described in detail in later posts) to facilitate this type of integration - but the developer still takes the key design decisions, and ultimately dictates the functionality and information architecture of the new application.

LM-entary, My Dear Watson
Theoretical physics has shown how a small number of fundamental particles can give rise to the hundred or so atoms in the Periodic Table, which in turn give rise to millions of different molecules. It’s strange to think that everything that surrounds us is essentially a specific recombination of the same very small building blocks. By extension, the various interactions between matter (and even life itself) are made possible by the fact that all matter is essentially compatible at the fundamental level. This is a useful, if slightly presumptuous, way of thinking about LM’s micro-component architecture, and it gives us an idea of the diversification which we hope will be possible in the Mixable Web.

In the next post we aim to show this isn’t all theoretical navel-gazing - although there’s been a lot of that too - by going through a real-world (and functioning) example application.

But for the time being, thanks for reading - and if you have any comments be sure to leave them below!