TOGAF Poster 18 – Deliverables, Artifacts and Building Blocks

TOGAF uses a very specific language to describe the outputs that architects produce. This poster highlights the key things you need to know. Download this free poster from Good e-Learning now!

Related posts:

  1. TOGAF Poster 17 – The Architecture Repository The Architecture Repository is where architects store work outputs. This…
  2. Learning TOGAF 9 Poster #27 – Business Transformation Readiness Enterprise Architecture usually applies to large scale and complex change….
  3. TOGAF and SOA Another free TOGAF poster from Good e-LearningPart III of TOGAF…

Deliverables, Artifacts And Catalogs-Matrices: Some examples

Quite often as an Enterprise Architects we are asked to show what the deliverables of an Enterprise Architecture program are.

TOGAF provides a methodology for analyzing your specific situation and turning that analysis into deliverables and actionable artifacts. Artifacts may have different shapes as defined in TOGAF 9. They may be: Catalogs, matrices or diagrams. EA artifacts may also help to define a standard set of document types such as education, strategy, decision, policy, standard, guideline, etc. It is also recommended that you set up a simple online discussion thread or wiki for each artifact to solicit feedback from artifact consumers.

Enterprise Architects should ensure that their efforts to create architecture documentation produce meaningful results by creating artifacts that connect with the consumer, drive decisions, and will allow the development of reusable building blocks.

If we consider the various architecture domains, they may have different forms.

As examples-
in Business Architecture, they could be the views of the Business stakeholders. The matrices between business strategy and the main business functions. The diagrams showing the relationship between processes and information. The Value Chains. Business and Operating models of the Enterprise. Customizing the configuration of the Business Functions according to model — and more.

The artifacts for Data or Information architecture may refer to an information map or diagram . It could also show the mapping between data items and the Business Information map.

Artifacts for Application Architecture, could show the key interconnections between applications, middleware connection matrices. There may also exists views for Portal Architecture, Enterprise Content Management , Identity management, Business Intelligence, ERPs and CRMs.

Last but not least, Technology Architecture artifacts may propose servers and storage technology diagrams, office views (file, printing, data base servers, etc…), LAN/WAN/Voice Network architecture diagrams, applications and interconnections mapping to technology servers and networks, infrastructure security diagrams. In addition to that, there may be a certain numbers of artifacts related to the company’s organization, organization chart, lines of business mapping to business functions, organization roles in organization units and job descriptions.
Many graphical tools may aid to develop diagrams or document matrices but may also be quite costly. The use of spreadsheet may be a first step in building artifacts such as matrices. The following examples illustrate how they may simply be build with Excel.

List of Metadata

Data-Business process matrix
Application Inventory List

These are very basic example of what artifacts may look like. They may rapidly be created and are definitely a way to explain to the EA stakeholders how the first deliverables of our baseline architecture looks like.

After the Plan: How Portfolio Visibility Carries Strategy Through Delivery

In complex portfolio environments, strong prioritization decisions are only as effective as the organization’s ability to sustain alignment during execution. Even when initiatives are evaluated rigorously, ranked objectively, and aligned to capacity targets, execution can drift if priorities, plans, dependencies, and risks are not consistently visible across teams and leadership. This blog post concludes the…

More Practicality, Less Theory

Enterprise Architecture frameworks are rarely questioned at the conceptual level. Most architects accept their value. Many organizations reference them explicitly. Certifications remain popular, methods are well known, and the language of architecture has become increasingly standardized across the profession. Yet something interesting happens when these frameworks enter daily practice: the translation becomes challenging, resulting in difficulty gaining stakeholder buy-in. However, stakeholder buy-in is not the issue.

The post More Practicality, Less Theory appeared first on EAWheel.