Reference Models, Reference Architectures and Reference Implemementations

I recently stumbled across a blog entry by J.D.Meier on the difference between Reference Models, Reference Architectures and Reference Implementations.  The difference between the first two was something that has never been entirely clear to me, so I found the post very useful.  


After reading this, my interpretation now, if I've understood it correctly, is that a Reference Model is a model of something that can be referred to for various purposes, such as when creating reference, or otherwise, architectures.  I think the SaaS/PaaS/IaaS Reference Model is the best illustration of this.  I suppose a glossary could, in a sense, be deemed a reference model.  I suppose you could call it a model of reference material.  Also, a Reference Model cannot be interpreted as an architecture itself.  


In contrast, a Reference Architecture appears to be, an architecture depicting a solution to a problem space to which other architectures and specifications can refer to.  Now this may be an generic architecture for a pattern, or an specific architecture for a specific problem, but either way it is the architecture which gives aerial views of the solution.


For example Open Group has a SOA Reference Architecture (as I'm sure a number of major players do). As pointed out, the MSDN pet shop application has a Reference Architecture.  Patterns can also have reference architectures, such as this one also from Microsoft.


I suppose Reference Architectures are used as inputs into Technical Architectures, Designs and Specifications, which in turn should refer back to the Reference Architectures.  I also believe that Reference Architectures are on the middle row of Zachman. 


Reference Implementations are the only implementations of Reference Architectures, and an proof and an example that the Reference Architecture is integral and as a guide to production implementations.  In my mind production implementations should never be created from Reference Architectures, they should only be created from the Technical Architectures, Designs and Specifications that are created from the Reference Architectures.


That's my understanding today anyway.

Architect Role and Skills

Here's an interesting presentation on the IASA's five pillars of architecture by Jim Wilt (Microsoft).

For background, the IASA determined the following pillars for IT architects:

• Business Technology Strategy: architects need basic business competence and understanding of the business of their business. Otherwise, they are not able to support their organization’s or customers' business goals. This knowledge comprises financials, IT business strategy innovation & validation, as well as industry concerns, trends, standards, and compliance.
• IT Environment refers to the architect’s “skills in the functional and procedural aspects of technology organization to ascertain solution and organizational maturity.” It is about running things and creating new things in terms of the application development processes, technical project management, leveraging platforms and frameworks, change management, asset management, governance, as well as testing and quality. For example, architects should be familiar with industry trends, understand the benefits and limitations of technologies, but also know about methodologies and technologies being used in their environment.
• Quality Attributes are mapped by IASA to four categories: Qualities that define usage aspects such as usability, developmental qualities such as changeability, operational aspects such as performance and last but not least, security. Such qualities are typically cross-cutting and lead to trade-offs due to constraints in time, cost, requirement and resources. Wilt emphasizes that these qualities need to be measurable and monitored. They also need to be practical. While customers might be interested in five nines of availability, they might not be willing to pay the price for achieving this quality goal.
• Design skills are an “architect’s primary tool in delivering architecture strategy and product to the business.” As Wilt emphasizes, it is not only about architecture creation but also about design review. It is not about “pretty pictures,” but about  “justifications, reasons, and trade off considerations” when capturing decisions. Skills required in this area include knowledge of design methodologies and techniques. Of course, architects should know tools for design, and also design artifacts such as patterns, styles or views. To achieve appropriate design decisions, architects must  be able to tie their decisions to business requirements.
• Human Dynamics is about managing and influencing people as well as interrelationships in the context of an IT project or environment. There are many skills required by architects in this context, as Wilt explains. They need to manage the culture but also deal with customer relations and with peers in the project environment. Although, architects mostly neither own line management nor project management responsibility, they require leadership and management skills. Collaboration and negotiation skills are essential. So are presentation and writing skills.

IASA have organised their skills matrix based on the five pillars, which is more of a course catalogue, but it's good food for thought.

As an alternative, it's always worth referring to the SFIA v5 skills framwork, particularily the section on strategy and architecture, and then there is always the TOGAF v9 skills framework.

Lastly, Graham Berrisford's presentation on EA vs SA roles is another interesting one.