• Explore More Strategy Topics

  Agile Agility Alignment Architecture Benchmark Business Cost Decision-Making Definition EA Enterprise Architecture Enterprise Archuitecture Execution Framework Good Enough Governance GTD Heuristic IEEE 1457 IT IT Governance ITIL Management Measurement Methodology Performance Planning Planninig Principle Principles Process Project Reference Architecture Research Security Simple Small Wins SOA Social Architecture Software Architecture Solution Standards Strategy Technology Thinking TOGAF Trends Zachman

• Blogroll

  • Enterprise Architecture: From Incite comes Insight…
  • Pragmatic Enterprise Architecture
  • Serge Thorn’s IT Blog
  • Smart (Enough) Systems
  • Technology Architecture & Projects
  • The Practice of Leadership
  • Todd Biske: Outside the Box
  • User-Centric Enterprise Architecture

Todd Biske wrote and interesting post on reference architecture which got me thinking… Todd asks the following two questions regarding reference architecture:

1. The first is whether or not a reference architecture should recommend specific technologies (e.g. “if you meet these conditions, you should use vendor product MagicFooBar”) or only describe the capabilities required, leaving implementations teams to choose a technology that fits (e.g. “the services tier must be exposed using XML-based interfaces”)?
2. How much guidance should a reference architecture give? Should it go so far as to place constraints on how individual classes are named, or how the file hierarchy is set up in the source code repository? Or should it remain at a level somewhere above the design of individual classes?

I agree with the view that reference architecture exists to provide guidance and for guidance to be useful it needs to be relevant to those using it. That is, reference architecture needs to be appropriate for the context in which it’s intended for use. This means that reference architecture is dependent on the stakeholders and the purpose for which it’s intended. Therefore, what constitutes reference architecture will differ from organisation to organisation. Given this Todd provides the following advice:

• A single, clear purpose for each deliverable: "….focus on delivering guidance that is singular in purpose, at least within a single deliverable… It means that you should avoid trying to answer all of the questions within a single (and likely very large) document. Rather, each deliverable should start with one simple question, and focus on answering that question clearly."
• Create a document hierarchy that moves from the general to the specific: "…The earlier documents discusses things more broadly, intending to answer the question of what collection of technologies are needed for a solution, but not necessarily guidance on the appropriate way to use that technology. For that, once the decision to use a particular technology has been made, a separate document goes into added depth, and the process continues. The reference material will eventually work its way down to development and operational guidelines (or hook up with those that may already exist)."

I thought that the above suggestions are really useful to keep in mind in our approach to reference architecture work. Any other thoughts and suggestions?

 

Technorati Tags: Reference Architecture, EA, Enterprise Architecture, Framework, Architecture

The IEEE 1471-2000 standard, also known as "Recommended Practice for Architectural Description of Software-Intensive Systems", describes a conceptual framework for architecture description and was published in October 2000. The scope of this recommended practice encompasses those products of system development that capture architectural information, where architectural descriptions are used for the following:

• Expression of the system and its evolution
• Communication among the system stakeholders
• Evaluation and comparison of architectures in a consistent manner
• Planning, managing, and executing the activities of system development
• Expression of the persistent characteristics and supporting principles of a system to guide acceptable change
• Verification of a system implementation’s compliance with an architectural description
• Recording contributions to the body of knowledge of software-intensive systems architecture

 

The IEEE 1471 Framework

The framework is conceptual and can be considered as a meta-framework, it does not specify the format or media for an architectural description, however it does specify certain, minimal required content of an architecture description. The key terms and concepts that are described by this framework includes:

• Architectural description (AD): A collection of products to document an architecture.
• System: A collection of components organized to accomplish a specific function or set of functions.
• System stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system.
• View: A representation of a whole system from the perspective of a related set of concerns
• Viewpoint: A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.
• Concerns: are those interests which pertain to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability.

 

click here for larger image

 

The framework can be described as follows:

• A system has one (1) architecture
• An architecture is described by one or more architectural descriptions
• An architectural description is composed of one or more of stakeholders, concerns, viewpoints, views, and models
• A stakeholder has one or more concerns
• A concern has one or more stakeholders
• A viewpoint covers one or more concerns and stakeholders
• A view conforms to one (1) viewpoint
• A viewpoint defines the method and patterns of a model
• A view has one or more models and a model is part of one or more views
• A viewpoint library is composed of viewpoints (reference architecture).

 

This conceptual framework provides an excellent foundation on which to build robust architectural descriptions. What I like about this framework is that it’s stakeholder and purpose focused, two factors that often become lost in an intensive architectural effort. All architecture must be stakeholder focused and deliver architectures that stakeholders can understand and which stakeholders can use for decision making.

• How well are you architectures described?
• Are the various stakeholder needs described and addressed with appropriate viewpoints?
• Are they understood, that is, have they resulted in the right technology decisions?

 

< Technorati Tags: IEEE, 1471, Standards, Views, Viewpoints, Architecture, Enterprise Architecture, EA, Framework, Methodology

Reference architectures are crucial tools that allow organisations to reduce the cost and time to implement technology solutions. In typical software projects a large amount of time is spent exploring technology options and assessing the appropriateness of solutions. This is where reference architecture provides the most value. As reference architectures are predefined and proven solutions to well described problems they can be confidently adopted by projects as part of their solution architecture, as illustrated in the figure below. These solutions can be quickly implemented by the organisation as they are based on previous implementation that are familiar to architects and developers.

Wikipedia defines a reference architecture as:

"…a proven template solution for an architecture for a particular domain. It also provides a common vocabulary with which to discuss implementations, often with the aim to stress commonality."

According to IBM’s RUP a reference architecture:

"…is, in essence, a predefined architectural pattern, or set of patterns, possibly partially or completely instantiated, designed, and proven for use in particular business and technical contexts, together with supporting artifacts to enable their use."

Considering the above definitions, a good reference architecture has the following characteristics:

• A repeatable solution: A reference architecture is a description of a solution that solves a specific recurring problem. It’s predefined by the organisation as an accepted approach to solving a specific problem within a domain. This allows the reference architecture to be used repeatedly, in numerous projects to solve similar problems.
• Proven: A reference architecture is a proven approach to solving the specific problem. By proven, we mean that is have been successfully used in previous projects and applications. Many of the reference architectures in use within the organisation have been recognised from successful implementations, documented for easy reuse.
• Descriptive: A reference architecture needs to be well described if it’s to be useful. The reference architecture need to assist with decision making by architects, project managers and developers. The reference architecture needs to describe what problem is solves, when it should be used and how it should used. It also should include standards that need to be implemented as part of the solution.

Well described reference architectures provide organisations with the following benefits:

• Provides a common domain-specific language for the various stakeholders
• Provide consistency of implementation of technology to solve problems
• Supports the validation of solutions against proved reference architectures
• Supports enterprise architecture and IT governance.
• Encourages adherence to common standards and patterns
• Encourages adoption of common asset reuse approaches

 

Are your solution architectures supported by proven reference architectures? How much reuse are you getting from your architectural efforts? What reference architecture should you be developing considering your enterprise application roadmap?

 

Technorati Tags: Reference Architecture,Architecture,Enterprise Architecture,EA,Project

• Search for:

• Welcome

  Welcome to Architecture and Change. You can subscribe to my blog using RSS or you can subscribe by e-mail

• Contact

  
  
  

• Busy Reading...

• Interesting Blog Stats

• Show of Support