Architects are fond of throwing terms around which have mixed, ambiguous or largely non-existent formal definitions. Indeed one of the great problems (still) of our profession is that people cannot agree on the meanings of many of the terms we use everyday. There is no ‘common language’ that all architects speak. If you want to see some examples look up terms like ‘enterprise architecture’ or ‘cloud computing’ in wikipedia then look at what’s written in the ‘discussion’ section.Three terms that often get misused or are used interchangeably fall under the general category of reusable assets. A reusable asset is something which has been proven to be useful, in some form or another, in one project or architectural definition and could be reused elsewhere. The Object Management Group (OMG) defines a reusable asset as one that: provides a solution to a problem for a given context. See the OMG Reusable Asset Specification. Those of you familiar with the classic Design Patterns book by the so called “Gang of Four” will recognise elements of this definition from that book. Indeed reusable assets are a generalization of design patterns. Three other reusable assets, which are of particular use to an architect, are:

• Reference architectures
• Application frameworks
• Industry solutions

What do each of these mean, what’s the difference and when (or how) can they be used?

A reference architecture is a template which shows, usually at a logical level, a set of components and their relationships. Reference architectures are usually created based on perceived best-practice at the time of their creation. This is both a good thing (you get the latest thinking) but can also be bad (they can become dated). Reference architectures are usually associated with a particular domain which could either be a business (e.g. IBM’s Insurance Application Architecture or IAA) or industry (such as a banking reference architecture) or technology domain (e.g. cloud and SOA). Ideally reference architectures will not preordain any technology and will allow multiple vendors products to be mapped to each of the components. Sometimes vendors use reference architectures as a way of placing their tools or products into a cohesive set of products that work together.

An application framework represents the partial implementation of a specific area of a system or an application. Reference architectures may be composed of a number of application frameworks. Probably one of the best known application frameworks is Struts from the Apache open source organisation. Struts is a Java implementation of the Model-View-Controller pattern which can be ‘completed’ by developers for their own applications.

Finally an industry solution is a set of pre-configured (or configurable) software components designed to meet specific business requirements of a particular industry. Industry solutions are usually created and sold by software vendors and are based on their own software products. However the best solutions adhere to open standards and would allow other vendors products to be used as well. Most organisations want to avoid vendor lock-in and are unlikely to take the “whole enchilada”. Industry solutions may be implementations of one or more reference architectures. For example IBM’s Retail Industry Framework implements reference architectures from a number of domains (supply chain, merchandising and product management and so on).

Assets can be considered in terms of their granularity (size) and their level of articulation (implementation). Granularity is related to both the number of elements that comprise the asset and the asset’s impact on the overall architecture. Articulation is concerned with the extent to which the asset can be considered complete. Some assets are specifications only, that is to say are represented in an abstract form, such as a model or document. Other assets are considered to be complete implementations and can be instantiated as is, without modification. Such assets include components and existing applications. The diagram below places the three assets I’ve discussed above in terms of their granularity and articulation.

There are of course a whole range of other reusable assets: design patterns, idioms, components, complete applications and so on. These could be classified in a similar way. The above are the ones that I think architects are most likely to find useful however.