Architecture Frameworks

Architecture Frameworks

• Sebaste

  (you missed TOGAF) Frameworks provide a broad (and sometimes deep) structure that guide the process of trawling for requirements and then elaborating and documenting the architecture that implements them. They also provide a standard terminology that simplifies communication with stakeholders and the project team.
  
  The first few times a framework is used, it's formality and scope can appear to be a straitjacket, directing the architect to consider aspects that are not relevant or timely. But achieving familarity with a framework allows the architect to treat it as a menu of actions and artifacts. With experience, a framework can even be used within an agile project by narrowing the selection and detail of artifacts down to the essential.
  
  With greater experience, it becomes possible to combine elements of frameworks. One I like, for example, is to use the logical structure of Zachman (which can be summarised on a single page) as a checklist, but use the process and artifacts of TOGAF.
  
  TOGAF's Vision Statement for example can be documented by covering the Zachman elements under the heading of Scope, especially Motivation. The Technical Architecture document spans the (logical) System Model elements with an introduction to the Technology Architecture and Contol Structure from the (physical) Technology Model elements.
  
  But a framework is worthless unless the architect has the political skills to unite the stakeholders, the technical skills to design a flexible solution that will meet known and yet unknown functional requirements, the experience to ensure the architecture will satisfy the non-functional requirements, the leadership skills to guide and motivate the project team, and the integrity to balance all the above.
  
  

• Harry Vijayakumar

  Colm Smyth wrote:

  (you missed TOGAF)...

  While you're at it - there are few other frameworks out there - some are domain specific like DODAF (which I already mentioned), FEAF (Federal EA Framework), TEAF (Treasury EA Framework) etc. and some are more general like IAF (by Cap Gemini Ernst & Young's), Gartner Framework, TAFIM, PERA (and Zachman, TOGAF) plus a few others

  Colm Smyth wrote:

  But a framework is worthless unless the architect has the political skills to unite the stakeholders, the technical skills to design a flexible solution that will meet known and yet unknown functional requirements, the experience to ensure the architecture will satisfy the non-functional requirements, the leadership skills to guide and motivate the project team, and the integrity to balance all the above.

  I totally agree - there are many soft skills architects should have to be successful

  you can also see the following two links David Ing's "An Overly Long Guide to Being A Software Architect" and my "Architect Soft Skills"

  Arnon

  
  
  

• eman_26

  Hi Clemens,< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

  Like most things in Software Architecture - it depends :)

  Sometimes the business circumstances requires that you use a framework e.g. if you are working with the US DOD you may need to work with DODAF; If your company standardized on Zachman you may need to use it etc.

  Another reason for looking at Architecture frameworks is that they can help you get started on understanding how to tackle architecture in an orderly manner (remember, though, that you still have to do the thinking by yourself :) )

   Note, however,  that many of the Architectural frameworks are for "Enterprise Architecture" (overall strategy of the organization), and as such may be a overkill for a solution architecture if that is what you are working on.

  Yet another reason  it is probably beneficial to get yourself acquainted with few of these frameworks is they can be used as a "view repository" when you try to figure out which viewpoints to use  to document your architecture - see slides 30-43  in http://www.rgoarchitects.com/Files/Architecture.ppt  (and also http://www.rgoarchitects.com/blog/PermaLink,guid,9b5b976a-efc2-4210-ab5e-ff712f1797f2.aspx)

  HTH,

  Arnon

  
  
  

• Mark_Hill

  my 2 cents.

  I think it is always a good idea to have some understanding various Enterprise Architecture frameworks such as Zachman or TOGAF, Meta etc. It doesn't really matter whether you are a solutions architect or IT Architect or Enterprise Architect as this knowledge will help you bring clarity and organization to various things that you do in an ad-hoc way today.

  For example, if you are a solutions architect and if your organization's Enterprise Architecture Team follows Zachman framework, then your understanding of Zachman framework will go a long way in implementing your solution as per the standard framework adopted by your larger organization. For instance,  when you are about to design your application (let's say procurement module), you may want to get a clarity on where the raw materials (data or entities) are present. This may have an implication on design of your app (for example, if customer/employee data is already present, do you really need another customer module or should you reuse the customer data. Zachman framework allows you document these things in a systematic way and this documentation will help you immensely). Also, Zachman framework lets you document your business processes and if your application participates in the business process, then studying the artifacts will be much help to you (assuming that you know how to study the artifacts in the first place, which leads to understanding of the framework).

  Bottomline, understanding of EA frameworks is always a good thing.

  
  
• Architecture Frameworks