Build vs. Buy* is a question faced by any significant development effort. Existing third party systems are available for most business functions, such as finance, content management, portals, CRM and many others (I'm not going to discuss the pedantic cases of operating systems, web servers and the like). For these kinds of functions buy is almost always the better alternative. My plan is not to discuss what kind of criteria you should make this evaluation on. Rather I intend to discuss the effects of buying a third party system will have on your application architecture.

For the purpose of this discussion I'm going to assume that the third party system you've got meets an actual business requirement and you're not just using it because you have it. The question then becomes how do you best take advantage of the third party system in building your solution. This is fundamentally a question of control and overall relevance to the business problem.

I refer to many third party systems as "control freaky", which is to say they insist on being in control of operations and user interactions. Their primary methods for supporting extension involves the development of components that run within the third party system. In extreme cases this may be in a proprietary language that only that system supports. This can present development challenges (such as making practices such as unit testing impossible) but fortunately is on the decline as more systems switch to Java or .NET for these capabilities.

When you choose to accept this model most of your architecture choices are made for you. The application architecture you have is primarily defined by the third party solution you are using. This doesn't mean you don't need to do proper design for the elements you wish to add as this is still important to the quality of your solution. What it does mean is that you can only implement your design within the contexts of the system it is an extension of.

In many cases this may be acceptable. For instance if you are building a public website that primarily consists of content to be served (as opposed to business functionality) then handing control to a content management system is not particularly onerous. A line of business application that has a small content management requirement (for example to store user help) is unlikely to be well suited to the restrictions a content management system enforces.

So does this imply that we must either live with the restrictions of a third party system or not use it at all? I don't believe so. Proper architecture can allow us to separate the elements to ensure that the constraints of a third party system do not constrain our entire solution. There are a number of ways we can achieve this.

With web based applications the simplest way to maintain separation is to have multiple websites. If these are given a common look and feel then the end user experience can be relatively seamless. Unless users pay attention to the page URLs in most cases they will see no indication that they are switching between a third party system and a custom developed application. Sharing data between the components may be implemented in a number of ways. Implementing targeted extensions inside the third party system that communicate with the custom application minimises the amount of work required in the context of the third party system while providing solid customisation options. This alternative implies that both applications would be part of the same service in an SOA context. Alternatively the applications could be configured to send each other messages allowing them to be separate services.

Another alternative may be to implement user interface elements within the third party system but to implement the business functionality in separate applications. This requires communication between the extensions and these applications. I don't particularly favour this approach as it tends to require more synchronous communication than may be desirable, and this can lead to temporal coupling and fragility. This may be reduced if you build it as a composite application but with a third part system involved the necessary separation may be hard to achieve.

Another integration possibility is to use the third party systems extensibility capabilities rather than its user interface. Provided such capabilities exist (and you should really not choose a system without them) this may be the preferred model in any case. If a system is incidental to the main purpose of your application there is a strong likelihood that the preferred interaction model for most usages of the system is as part of the business process. In this case automated interaction is preferable to requiring manual interaction.

This model allows the third party systems to be placed behind a service boundaries (chosen on business requirements, not simply defined by the third party systems being used). This will isolate the other elements of your solution from the constraints of these systems.

To summarise: Use of third party systems is necessary and desirable but may introduce undesirable architecture constraints. The use of these systems should therefore be controlled such that they are applied to the relevant portions of a business problem but do not negatively impact the solution to business problems they are not relevant to. When designing a solution you should ensure that you have a clear understanding of these issues and that your architecture allows for clear separation of these elements.

* Buy in this context can also refer to using an open source product for which there is no software licensing cost. Such software still carries costs in terms of developer familiarisation and training and ongoing operational costs.