The trouble with software architecture is that it keeps getting re-invented and new acronyms appear followed by a slew of large unreadable books explaining why this new architecture is going to change everything. This is actually a widespread phenomenon in the software industry of many emerging approaches/solutions/tools/languages/frameworks/patterns/protocols where adoption rules supreme resulting in a form of natural selection. It is perhaps inherent in the nature of software that such flexibility results in so many solutions to the same problem. A good guide through this maze is a pragmatically tuned intuition that tells you when something is unnecessarily complex to be effective. Keeping things simple means more people will adopt, use, discuss and improve it. A good example would be RESTful services that are gaining in adoption due to their simple clear approach to exposing services through HTTP.
What is AOA ?
With all of the above taken into consideration then I want to introduce yet another architectural meme, namely Assembly Oriented Architecture (AOA). This is more of an approach with some guidelines and doesn’t require any standards or reference documentation to understand in order to apply it. It is an approach that has evolved from real practical experience and is actively used on all projects that Optaros works on so is well proven in the field.
At Optaros we focus on assembling open source solutions which are often very strong on supporting open standards that lend themselves to assembly. However proprietary solutions can also be assessed in terms of their ability to be part of an assembled solution.
Guiding principles for selecting AOA solutions
- Lightweight standards based interfaces covering key functionality and data access. For web based solutions these interfaces should be web oriented such as RESTful services and support returning different formats such as XML, JSON and HTML.
- Supports open standards such as OpenID, OAuth, RDF, CMIS etc
- Can the solution be easily disassembled – ie can the built-in search or authentication mechanism be easily switched to use another
Why use AOA ?
Using AOA is around fast delivery of robust, flexible architectures. It is inherently pragmatic accepting that most real world solutions are largely comprised of combining disparate applications and not nicely packaged services. More explicitly the benefits of using it are as follows :-
- Results in clean standards based architecture without getting locked in to a particular solution
- Less coding – gaps are plugged by identifying suitable applications or components that meet the need and are assembly friendly
- Faster to deploy than custom build
- Best components for the job and ease of changing them out when something better comes along
- Lower cost of ownership compared to either custom build or customising an off the shelf application due to the above benefits
How it differs from SOA ?
Enterprise Architect’s at this point might be thinking surely this is what SOA is intended to provide, a clean architecture that allows the different systems to be replaced as needed without breaking any of the interfaces. I should firstly say that AOA is not an alternative to SOA they are completely compatible architectural approaches and I would go further to suggest that both should be adopted to ensure a clean, flexible and robust architecture. SOA differs from AOA in a number of different areas namely
- SOA is concerned with defining clean services independent of any specific application, whereas AOA is about selecting applications that are Assembly friendly
- AOA looks to have applications that can themselves be disassembled and easily configured to use external components for some areas of functionality such as workflow, rules, search etc whereas SOA would define services for key capabilities and invoke the relevant application interface
- SOA is more about providing a layer of abstraction on top of applications whereas AOA is about effectively combining applications to deliver a solution
- Although not directly tied to SOA there is the whole area of Web Services and associated specifications – AOA doesn’t go to the level of detail specifications but relies on guiding principles
In my experience SOA can be taken too far and alot of time spent agreeing every possible service to cover all of the combined functionality of all of the main applications. So it can turn into a time and money pit with no real clear business value. SOA seems to work best when common services that will be called by many systems are developed rather than trying to boil the functional ocean. The other area that alot of time can be lost is in the dark depths of the many WS-* standards that exist – again that pragmatic intuition should steer you clear of distractions from the task at hand when developing useful services.
A number of patterns are starting to emerge for different types of assembly architecture – the following is a list of the common ones.
- Plug-in Platform – Assemble a solution around a central component covering the core functionality and acting as the integration platform for assembling the missing parts, thanks to its extensible architecture.
- Container Assembly – Assemble a solution around a central container not providing any business functionality but focusing on cross cutting concerns (security, logging, access to resources, …). This framework should be a standard (or de-facto standard) of the other components you want to assemble.
- Service Oriented Assembly – Assemble a solution using a SOA approach. Each component to be assembled should provide a public interface that would be used for integration.
In the end pragmatism wins, technologies continue to change and no matter what is done to try and allow for that in an architecture, ultimately effort is needed to accommodate those changes. Given that reality check it should be clear that spending months developing intricate service definitions for everything is probably not good for anyone. Therefore AOA offers good guidelines and actually helps deliver solutions faster while allowing for applications and components to be changed in the future as required.