The architecture of TOGAF will be depending on relating a number of architectural structure blocks within the architecture address list, describing the association between those building wedge within the architecture mediums, and providing statement diagrams that show in an exact and brief way the architecture is.

Meta-model Concepts

This part explain the core concepts of the TOGAF content meta-model, by the subpart as below.
Core and Extension Content: describes the about how TOGAF employs a basic core meta-model and then applies a number of extension modules to address specific architectural issues in more detail.
Core Meta-model Entities: defines the main TOGAF meta-model entities, presenting the intension of each and he key relationship that support architectural compatibility.
Catalogue, matrix, and diagram concept: Here you can find the description of the concepts of catalogues, matrices and diagrams.

 TOGAF Certification

If you want to brighten your career in the field of TOGAF , owning certification in the same will add more value in the present platform of TOGAF. TOGAF stands in the first list when we deal with project architectures in all scales. TOGAF certification may guarantee for 30% of job assurance and in some cases the certification will be of less importance. So for some of the enterprise architects it is just another drivers licence. That indicates you are just a driver but, not a good driver. But it should be notable that, the some of the companies need certification as a entry ticket for some of the jobs.

TOGAF And Finding Tool Support

It is compulsory that both users and developers must have tools. Tools like online help are specifically designed for users and tried to use the languages of the consumer. Various different tools exist for several kinds of developers, but they suffer from lack of a usual language that needs to be bringing the system together. It is quite a hurdle, or impossible to interpret one tool with another in the current state of the tools market.
Views and viewpoints in Enterprise Architecture

Let’s consider two stakeholders in a new tiny computing system- the users and the developers.

The viewpoint of the users of the system will get reflected their concerns when communicating with the system, as well the viewpoint of the developers of the systems will be different from those of others. The observations that are developed to address either of the two viewpoints are not same thoroughly and describe the wholesome system because each perspective reduces how each look into the system.

The observations and opinions of the user will be depending on the way the user interacts with the system, the user never concerned about the details like applications or Database Management Systems (DBMS).

The viewpoint of the developer is recognized as one of the products and tools, and never includes the things like actual live data and connections with the users.

All the way, there will be things shared, like descriptions of the processes that are allowed by the system and communications protocols set up for the users to converse problems straight to the developers.

In this particular instance, one viewpoint is the explanation of how the user looks into the system, and one more viewpoint is how the developers see the system. The aspects that users use to describe the system are modelled availability, response time and access and the data for accessing.

The aspects described by the developers to describe the system are using a model of software connected to hardware distributed over a network and so on. Anyhow, various kinds of development of the system and they do not have a usual language derived from the model.


Leave a Reply

Your email address will not be published. Required fields are marked *

Solve : *
28 + 27 =