• 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

 

Mike Walker wrote and interesting post on a discussion he had on “Making Sense of Architecture Standards" which resulted in the following image:

 

 

• Taxonomy and Ontology: Such as IEEE 1471, “. . .an architecture is a conception of a system. There may be many conceptions of a system… What this provides to the enterprise architect, solutions architect or domain architect is a way to have a constant set of terms for describing what it is they are building. This should be at the core to your architecture activities.”
• Information Model and Decision Support: Decision support help us to "..focus more on … What are the right questions  … How do I organize those questions … What do those answers mean … Meaning what is the process in which I get the information, consume it, process it and ultimately make it actionable."
• Process Framework: "… when talking about decision support, there is a need for a process to wrap how we make our decisions…. Having this higher level process framework is essential to architects. There are a series of benefits for the organization … Constancy in how solutions are created … The right people are selected for the right job … Proper metrics can be obtained to gauge health of the EA process … Predictability of results which lends to being able to apply some level of risk management to decisions"
• Actors: These are people with the appropriate skills and competencies.
• Manage: The ability to effectively execute strategy and tactics "…This aspect covers PMO based processes, service management and IT Governance aspects. In the service management area specifically we are seeing closer alignment with EA. The latest version of ITIL has alignment with EA practices."

This is a great overview of the enterprise architecture standards and how they relate and interact.

 

Technorati Tags: EA, Enterprise Architecture, Framework, Standards, ITIL, TOGAF, IAF, Zachman, IEEE 1457, PMO, Process

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

TOGAF (The Open Group Architecture Framework) defines an architecture framework as follows:

"An architecture framework is a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks."

This definition provides a TOGAF view of what an architectural framework should do….

• An architectural framework provides the necessary methodology or method by which the architecture tasks and activities are done.
• An architectural framework provides the definition of the deliverables that the architecture methodology should / must produce.

I like this definition, as many frameworks provide a description of the deliverables, but provide little guidance on how to go about producing the required deliverables. Neglecting the methodology can have sever consequences, such as, weak governance, poor IT business alignment and a lack of buy-in.

How effective is your architectural framework?

Technorati Tags: Framework, Methodology, Definition, TOGAF, Enterprise Architecture, 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

I like to describe architecture as the "art and science of seeing the big picture, it’s components and their inter-relationships". In the book "The art of systems architecting" the authors describe architecture as both and art and a science.

 

 

• Normative - solution-based: This architecture method is founded on a strong science-based approach, prescribing architecture as is should be, as it’s described in building codes, handbooks and civil codes. This method for the development of architecture create well defined patristic architecture.
• Rational - method-based: This architecture method is founded on a strong mathematical and scientific principles to arrive at a solution, strongly based on systems analysts and engineering.
• Participative - stakeholder-based: This architecture method is founded on understanding he complexities that exists when working with multiple stakeholders. The objective of the approach is to reach consensus. Concurrent engineering and brainstorming a both tools used in this method, typically this is approach us characterised as "architecture by committee".
• Heuristic - lessons-learned: This architecture method is founded on common sense, driven by what is sensible in the given context. This contextual sense results from the collective experience of those involved in the architecture. Heuristics or lessons learned from experience, for example to simplify, are used as guides in the development of the architecture.

 

Considering the holistic nature of enterprise architecture and the complexities involved, the integration of these four classic architectural methods into how we develop enterprise architecture make for a robust outcome. The enterprise architecture methodology used needs to integrate these four paradigms.

• Is your architecture methodology solution-based?
• Is your architecture methodology method-based?
• Is your architecture methodology heuristic-based?
• Is your architecture methodology stakeholder-based?

 

Technorati Tags: Methodology, Framework, EA, Enterprise Architecture, Architecture,Stakeholder, Art, Science, Method, Management,Technology

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