omg

Reusable Assets for Architects

Peter Cripps architecture ,

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.

When Does an Architecture Become a Reference Architecture?

Peter Cripps architecture , ,

A reference architecture (RA) is a particular kind of reusable asset that is basically a “ready-rolled” architecture that has been used and proven in a number of other situations and can be applied (wholly or partly) to to solving different problems (though within a particular context). The question is, when does the  architecture of a system become one that can be reused elsewhere and therefore become a reference architecture? I have a colleague, Bruce Anderson, who was instrumental in the early pattern movement who once said to me that something can only be called a pattern if there are at least three known instances of it. One of the things that made the famous Design Patterns book so powerful and continues to make it so enduring is that it was based on rigorous research by the authors who trawled through several systems designs to look for common themes and harvest them into the catalogue of patterns that make up the book. Whilst a reference architecture could be considered a kind of pattern it has some differences that make it harder to find multiple instances that are already ‘out there’. Namely:

  1. A reference architecture is, by definition, a large-grained asset typically made of  many subsystems which in turn are made up of interdependent components. There are many ways of assembling these components together, any one of which will usually do the job. It is unlikely therefore that exactly the same assembly of subsystems and components will exist in more than one architecture. Consider the architecture of an online retail store for example. There will be subsystems for allowing new customers to register and change there contact details, managing the ordering process and for managing the database of products that are for sale. However the internal components that make up these subsystems could be wired together in many different ways. Who is to say which is best?
  2. Architectures at the system level are typically documented in a multitude of different ways. Some may use rigorous modelling languages such as SysML captured in a modelling tool whilst others use more informal documentation consisting of pictures and words captured using a word processor. This makes it difficult to compare like with like when trying to find “best of breed” which is, after all, what we are trying to do when harvesting architectural assets.
  3. Large-grained assets consisting of complete architectures are likely to contain a considerable amount of intellectual property that give companies competitive advantage so they are unlikely to offer them up as potentials for becoming an industry reference. Some subsystems my be covered by patents (amazon’s one-click ordering for example) so are at least accessible but many will not be generally available for anyone to view.

These three factors (and there are probably more, feel free to comment) make it difficult to find similar architectures, compare them to see which is best and to harvest them as a reference for others to use which is the whole intent of the patterns movement. What to do?

  1. Reference architectures can be built. With an enterprise, a bank for example, it should be possible to build a reference architecture bottom-up. By deploying architects with the right industry and technology skills components can be selected and assembled in an optimum way that makes most sense for that organisation. This can then be a reference for other parts of the organisation to use. For companies that provide consultancy across multiple clients this can be a very powerful way to achieve reuse across projects however it does require a significant up-front investment as well as ongoing maintenance to keep the architecture current.
  2. Reference architectures should be described using a standard approach. It helps to document architectures using a standard set of work products. In the book The Process of Software Architecting we describe a set of work products that can be used for documenting a systems architecture (Architecture Overview, Functional Model, Deployment Model, Architecture Decisions etc). The point about using a standard set of work products to describe a reference architecture is that these can then form the basis of the documentation of the system that is to be built based on the reference system.
  3. Reference architectures are made to be changed, not used as-is. Once a reference has been defined it will almost certainly be changed to a lesser or greater extent depending on its “fit-gap” to the requirements of the new system. It’s usually worthwhile to do a formal fit-gap analysis to determine this and to use the output as part of the documentation of the new system.
  4. For reference architectures context is critical. This really follows from the previous item. Knowing the context (functional and non-functional requirements) is critical to the applicability of a reference architecture being reused. There is a danger it will be forced to fit when it makes no sense to do so. For example the new system has particularly stringent performance requirements that mean the way components are wired together in the reference architecture cannot be applied to the new system.

A reference architecture is associated with a particular domain of interest (retail banking, online commerce etc) and typically includes many different architectural patterns, applied in different areas of its structure. Since a reference architecture is an architecture, it is no surprise to find that the best  reference architectures are described in exactly the same manner as any other architecture using the same work products.