2 years, 3 months ago

Levels of Architectural Understanding

Early on in my EA career, I was very fortunate to become involved in a pioneering EA initiative at Westpac. My introduction to Westpac came when I helped its Group Data Resource Management team develop tool and repository support for its enterprise business model. During this engagement, I kept hearing people refer to an exciting Read more

2 years, 3 months ago

Levels of Architectural Understanding

Early on in my EA career, I was very fortunate to become involved in a pioneering EA initiative at Westpac. My introduction to Westpac came when I helped its Group Data Resource Management team develop tool and repository support for its enterprise business model. During this engagement, I kept hearing people refer to an exciting Read more

4 years, 11 months ago

Documenting Design Decisions

We previously discussed Options Analysis – our method for evaluating multiple viable technical solutions.  We also facilitate numerous smaller design choices at all levels of the architecture.  We often need to document these as “design decisions,” and use a common approach and format to document at all levels of design (conceptual, logical, physical, component, etc.). […]

4 years, 11 months ago

Prose: Great for Novels, Lousy for Solution Design

While we often find ourselves advocating for design documentation, we typically are referring to “some” design documentation vs. “more” design documentation.  When it comes to design documentation, more is actually not better.  We have encountered customers, and even other consulting firms, that deliver design documentation by the inch – measuring design quality horizontally across the […]

5 years, 2 months ago

Using CMU/SEI Quality Attribute Workshop (QAW) while developing an Architecture Vision

Business Scenarios are a proven technique to link business requirements to architectural models. According to TOGAF a Business Scenario is a description of:

  • A business process, application, or set of applications that can be enabled by the architecture
  • The business and technology environment
  • The people and computing components (called “actors”) who execute the scenario
  • The desired outcome of proper execution”

Recently I have been working with another technique which is commonly used by Software Engineering People but mainly for Software Architecture: Quality Attribute Workshops (QAWs) from CMU SEI (Carnegie Mellon Software Engineering Institute. This technique make use of interactive workshops with the main stakeholders of a project. Where you the solution is to be developed either internally or externally (not a COTS), then this technique could be combined with the Business Scenario.
A Quality Attribute Workshop (QAW) is a systematic approach to elicit the needed requirements. This will ensure that all quality attributes are included in the final design. To This end it:

  • is a facilitated method that engages system stakeholders early in the life cycle to discover the driving quality attributes of a software-intensive system
  • provides a way to identify important quality attributes and clarify system requirements before the software architecture has been created (Implementation Governance)
  • is based on the qualities and the non-functional requirements that may be captured in the Architecture Vision document, the team will identify and elaborate specific quality attribute scenarios and document them
  • produces a documentation that includes most of the quality attributes specified by the stakeholders

QAW defines two kinds of architectures:

  • System Architecture: the fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviours
  • Software Architecture: the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them

The TOGAF specification considers the Enterprise as a System, however the term System in QAW is more related to IT Systems. QAW provides an opportunity to gather stakeholders together to provide input about their needs and expectations with respect to key quality attributes that are of particular concern to them. A similar concept to what we try to achieve with the TOGAF Business Scenario but with a focus on IT systems quality attributes.

It is also a purpose of identifying scenarios from the point of view of a diverse group of stakeholders which can then be used by the system engineers to analyse the system’s architecture and identify concerns. QAW is mainly addressing non-functional requirements and there is still needs to understand the problems we try to solve, gather functional requirements like in Business Scenarios.

clip_image002
Quality Attribute Workshops ensure that quality attribute scenarios are identified, prioritized, and refined before the software architecture is completed. Individual requirements are viewed in a forum in relation to one another in the context of the overall problem. Architecture is based on complete set of requirements that add up to a whole problem description.

Technique requires involvement – at an early stage in architecture project

  • Business stakeholders (end users)
  • Systems stakeholders (installers, administrators, DBAs; network, training, acquirers, system and software engineers, etc.)
  • Other stakeholders (such as Operations amongst others)

The QAW provides:

  • Increased stakeholder communication, an informed basis for architectural decisions
  • Improved architectural documentation, and support for analysis and testing throughout the life of the system

And the results include:

  • A list of architectural drivers
  • Raw scenarios
  • A prioritized list of raw scenarios
  • Refined scenarios

During the workshops the Stakeholders receive a “participant’s handbook” providing example quality attribute taxonomies, questions, and scenarios.

Below are the steps of the QAW.

clip_image004
clip_image006
clip_image008
clip_image010
Business and/or mission drivers for the system (goals and drivers), plan, strategies, high-level functional requirements, constraints, artifacts and quality attribute requirements should be presented to the stakeholders. Using Business Scenario in conjunction with QAWs can be an appropriate approach.

A QAW lends itself to the capture of many architecturally relevant materials:

  • Software architectural documentation is a collection of view packets plus any documentation that applies to more than one view
  • Each view packet contains a primary presentation, a catalogue of the view’s elements (including element behaviour), use case diagrams, sequence diagram, context diagrams, collaboration diagram, a variability guide, architecture background (rationale, analysis results, and assumptions about the environment), and other information including mapping to requirements

These elements may also be produced in a Business Scenario or produced later in the ADM phases A : Architecture Vision, C: Information Systems Architectures (stakeholders management and taxonomy of artifacts).

clip_image012
The outputs from the QAW can be summarised as:

  • A list of architectural drivers
  • Raw scenarios
  • A prioritized list of raw scenarios
  • Refined scenarios
  • Questionnaire

Quality attribute requirements are the means by which a system is intended to meet its business goals and QAW helps to document them.

Software architectures must be designed so that their quality attributes are met.

The QAWs technique can be utilised as a complementary approach to gather all sort of requirements including those from Software Architectures when appropriate.

5 years, 2 months ago

Using CMU/SEI Quality Attribute Workshop (QAW) while developing an Architecture Vision

Business Scenarios are a proven technique to link business requirements to architectural models. According to TOGAF a Business Scenario is a description of:

  • A business process, application, or set of applications that can be enabled by the architecture
  • The business and technology environment
  • The people and computing components (called “actors”) who execute the scenario
  • The desired outcome of proper execution”

Recently I have been working with another technique which is commonly used by Software Engineering People but mainly for Software Architecture: Quality Attribute Workshops (QAWs) from CMU SEI (Carnegie Mellon Software Engineering Institute. This technique make use of interactive workshops with the main stakeholders of a project. Where you the solution is to be developed either internally or externally (not a COTS), then this technique could be combined with the Business Scenario.
A Quality Attribute Workshop (QAW) is a systematic approach to elicit the needed requirements. This will ensure that all quality attributes are included in the final design. To This end it:

  • is a facilitated method that engages system stakeholders early in the life cycle to discover the driving quality attributes of a software-intensive system
  • provides a way to identify important quality attributes and clarify system requirements before the software architecture has been created (Implementation Governance)
  • is based on the qualities and the non-functional requirements that may be captured in the Architecture Vision document, the team will identify and elaborate specific quality attribute scenarios and document them
  • produces a documentation that includes most of the quality attributes specified by the stakeholders

QAW defines two kinds of architectures:

  • System Architecture: the fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviours
  • Software Architecture: the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them

The TOGAF specification considers the Enterprise as a System, however the term System in QAW is more related to IT Systems. QAW provides an opportunity to gather stakeholders together to provide input about their needs and expectations with respect to key quality attributes that are of particular concern to them. A similar concept to what we try to achieve with the TOGAF Business Scenario but with a focus on IT systems quality attributes.

It is also a purpose of identifying scenarios from the point of view of a diverse group of stakeholders which can then be used by the system engineers to analyse the system’s architecture and identify concerns. QAW is mainly addressing non-functional requirements and there is still needs to understand the problems we try to solve, gather functional requirements like in Business Scenarios.

clip_image002
Quality Attribute Workshops ensure that quality attribute scenarios are identified, prioritized, and refined before the software architecture is completed. Individual requirements are viewed in a forum in relation to one another in the context of the overall problem. Architecture is based on complete set of requirements that add up to a whole problem description.

Technique requires involvement – at an early stage in architecture project

  • Business stakeholders (end users)
  • Systems stakeholders (installers, administrators, DBAs; network, training, acquirers, system and software engineers, etc.)
  • Other stakeholders (such as Operations amongst others)

The QAW provides:

  • Increased stakeholder communication, an informed basis for architectural decisions
  • Improved architectural documentation, and support for analysis and testing throughout the life of the system

And the results include:

  • A list of architectural drivers
  • Raw scenarios
  • A prioritized list of raw scenarios
  • Refined scenarios

During the workshops the Stakeholders receive a “participant’s handbook” providing example quality attribute taxonomies, questions, and scenarios.

Below are the steps of the QAW.

clip_image004
clip_image006
clip_image008
clip_image010
Business and/or mission drivers for the system (goals and drivers), plan, strategies, high-level functional requirements, constraints, artifacts and quality attribute requirements should be presented to the stakeholders. Using Business Scenario in conjunction with QAWs can be an appropriate approach.

A QAW lends itself to the capture of many architecturally relevant materials:

  • Software architectural documentation is a collection of view packets plus any documentation that applies to more than one view
  • Each view packet contains a primary presentation, a catalogue of the view’s elements (including element behaviour), use case diagrams, sequence diagram, context diagrams, collaboration diagram, a variability guide, architecture background (rationale, analysis results, and assumptions about the environment), and other information including mapping to requirements

These elements may also be produced in a Business Scenario or produced later in the ADM phases A : Architecture Vision, C: Information Systems Architectures (stakeholders management and taxonomy of artifacts).

clip_image012
The outputs from the QAW can be summarised as:

  • A list of architectural drivers
  • Raw scenarios
  • A prioritized list of raw scenarios
  • Refined scenarios
  • Questionnaire

Quality attribute requirements are the means by which a system is intended to meet its business goals and QAW helps to document them.

Software architectures must be designed so that their quality attributes are met.

The QAWs technique can be utilised as a complementary approach to gather all sort of requirements including those from Software Architectures when appropriate.

5 years, 6 months ago

Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0

One of the responsibilities of an Enterprise Architect is to provide complete traceability from requirements analysis and design artefacts, through to implementation and deployment.

Along the years, I have found out that the term traceability is not always really considered in the same way by different Enterprise Architects.

Let’s start with a definition of traceability. Traceable is an adjective; capable of being traced. Trying to find a definition even from a dictionary is a challenge and the most relevant one I found on Wikipedia which may be used as a reference could be “The formal definition of traceability is the ability to chronologically interrelate uniquely identifiable entities in a way that is verifiable.”

In Enterprise Architecture, traceability may mean different things to different people.

 

Some people refer to

· Enterprise traceability which proves alignment to business goals

· End-to-end traceability to business requirements and processes

· A traceability matrix, the mapping of systems back to capabilities or of system functions back to operational activities

· Requirements traceability which assists in quality solutions that meets the business needs

· Traceability between requirements and TOGAF artifacts

· Traceability across artifacts

· Traceability of services to business processes and architecture

· Traceability from application to business function to data entity

· Traceability between a technical component and a business goal

· Traceability of security-related architecture decisions

· Traceability of IT costs

· Traceability to tests scripts

· Traceability between artifacts from business and IT strategy to solution development and delivery

· Traceability from the initial design phase through to deployment

· And probably more

 

The TOGAF 9.1 specification rarely refers to traceability and the only sections where the concept is used are in the various architecture domains where we should document a requirements traceability report or traceability from application to business function to data entity.

The most relevant section is probably where in the classes of architecture engagement it says:

“Using the traceability between IT and business inherent in enterprise architecture, it is possible to evaluate the IT portfolio against operational performance data and business needs (e.g., cost, functionality, availability, responsiveness) to determine areas where misalignment is occurring and change needs to take place.”

And how do we define and document Traceability from an end user or stakeholder perspective? The best approach would probably to use a tool which would render a view like in this diagram:

image

 

In this diagram, we show the relationships between the components from the four architecture domains. Changing one of the components would allow doing an impact analysis.

Components may have different meanings as illustrated in the next diagram:

 

image

Using the TOGAF 9.1 framework, we would use concepts of the Metamodel. The core metamodel entities show the purpose of each entity and the key relationships that support architectural traceability as stipulated in the section 34.2.1 Core Content Metamodel Concepts.

So now, how do we build that traceability? This is going to happen along the various ADM cycles that an enterprise will support. It is going to be quite a long process depending on the complexity, the size and the various locations where the business operates.

 

There may be five different ways to build that traceability:

· Manually using an office product

· With an enterprise architecture tool not linked to the TOGAF 9.1 framework

· With an enterprise architecture tool using the TOGAF 9.1 artifacts

· With an enterprise architecture tool using ArchiMate 2.0

· Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

 

1. Manually using an office product

You will probably document your architecture with the use of word processing, spread sheets and diagramming tools and store these documents in a file structure on a file server, ideally using some form of content management system.

Individually these tools are great but collectively they fall short in forming a cohesive picture of the requirements and constraints of a system or an enterprise. The links between these deliverables soon becomes non manageable and in the long term impact analysis of any change will become quite impossible. Information will be hard to find and to trace from requirements all the way back to the business goal that drives it. This is particularly difficult to achieve when requirements are stored in spread sheets and use cases and business goals are contained in separate documents. Other issues such as maintenance and consistency would have to be considered.

clip_image006

 

2. With an enterprise architecture tool not linked to the TOGAF 9.1 framework

Many enterprise architecture tools or suites provide different techniques to support traceability but do not really describe how things work and focus mainly on describing requirements traceability. In the following example, we use a traceability matrix between user requirements and functional specifications, use cases, components, software artifacts, test cases, business processes, design specifications and more.

Mapping the requirements to use cases and other information can be very labor-intensive.

clip_image008

Some tools also allow for the creation of relationships between the various layers using grids or allowing the user to create the relationships by dragging lines between elements.

Below is an example of what traceability would look like in an enterprise architecture tool after some time. That enterprise architecture ensures appropriate traceability from business architecture to the other allied architectures.

 

clip_image010

 

3. With an enterprise architecture tool using the TOGAF 9.1 artifacts

The TOGAF 9.1 core metamodel provides a minimum set of architectural content to support traceability across artifacts. Usually we use catalogs, matrices and diagrams to build traceability independently of dragging lines between elements (except possibly for the diagrams). Using catalogs and matrices are activities which may be assigned to various stakeholders in the organisation and theoretically can sometimes hide the complexity associated with an enterprise architecture tool.

 

image

Using artifacts creates traceability. As an example coming from the specification; “A Business Footprint diagram provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified”. There are other artifacts which also describe other traceability: Data Migration Diagram and Networked Computing/Hardware Diagram.

 

4. With an enterprise architecture tool using ArchiMate 2.0

Another possibility could be the use of the ArchiMate standard from The Open Group. Some of the that traceability could also be achievable in some way using BPMN and UML for specific domains such as process details in Business Architecture or building the bridge between Enterprise Architecture and Software architecture.

With ArchiMate 2.0 we can define the end to end traceability and produce several viewpoints such as the Layered Viewpoint which shows several layers and aspects of an enterprise architecture in a single diagram. Elements are modelled in five different layers when displaying the enterprise architecture; these are then linked with each other using relationships. We differentiate between the following layers and extensions:

· Business layer

· Application layer

· Technology layer

· Motivation extension

· Implementation and migration extension

The example from the specification below documents the various architecture layers.

clip_image014

As you will notice, this ArchiMate 2.0 viewpoint looks quite similar to the TOGAF 9.1 Business Footprint Diagram which provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified.

Another example could be the description of the traceability among business goals, technical capabilities, business benefits and metrics. The key point about the motivation extension is to work with the requirement object.

Using the motivation viewpoint from the specification as a reference (motivation extension), you could define business benefits / expectations within the business goal object, and then define sub-goals as KPIs to measure the benefits of the plan and list all of the identified requirements of the project / program. Finally, you could link these requirements with either application or infrastructure service object representing software or technical capabilities. (Partial example below).

 

clip_image016

 

One of the common questions I have recently received from various enterprise architects is “Now that I know TOGAF and ArchiMate… how should I model my enterprise? Should I use the TOGAF 9.1 artifacts to create that traceability? Should I use ArchiMate 2.0? Should I use both? Should I forget the artifacts…”. These are good questions and I’m afraid that there is not a single answer.

What I know is that if I select an enterprise architecture tool supporting both TOGAF 9.1 and ArchiMate 2.0, I would like to be able to be able to have a full synchronization. If I model a few ArchiMate models I would like my TOGAF 9.1 artifacts to be created at the same time (catalogs and matrices) and if I create artifacts from the taxonomy, I would like my ArchiMate models also to be created.

Unfortunately I do not know the current level of tools maturity and whether tools vendors provide that synchronization. This would obviously require some investigation and should be one of the key criteria if you were currently looking for a product supporting both standards.

 

5. Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

This other possibility requires that you have an up to date Configuration Management Database and that you developed an interface with your Architecture Repository, your enterprise architecture tool. If you are able to replicate the relationships between the infrastructure components and applications (CIs) into your enterprise architecture tool that would partially create your traceability.

If I summarise the various choices to build that enterprise architecture traceability, I potentially have three main possibilities:

 

image

 

Achieving traceability within an Enterprise Architecture is key because the architecture needs to be understood by all participants and not just by technical people.  It helps to incorporate the enterprise architecture efforts into the rest of the organization and it takes it to the board room (or at least the CIO’s office) where it belongs.

· Describe your traceability from your Enterprise Architecture to the system development and project documentation.

· Review that traceability periodically, making sure that it is up to date, and produce analytics out of it.

If a development team is looking for a tool that can help them document, and provide end to end traceability throughout the life cycle EA is the way to go Make sure you use the right standard and platform. Finally, communicate and present to your stakeholders the results of your effort.

5 years, 6 months ago

Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0

One of the responsibilities of an Enterprise Architect is to provide complete traceability from requirements analysis and design artefacts, through to implementation and deployment.

Along the years, I have found out that the term traceability is not always really considered in the same way by different Enterprise Architects.

Let’s start with a definition of traceability. Traceable is an adjective; capable of being traced. Trying to find a definition even from a dictionary is a challenge and the most relevant one I found on Wikipedia which may be used as a reference could be “The formal definition of traceability is the ability to chronologically interrelate uniquely identifiable entities in a way that is verifiable.”

In Enterprise Architecture, traceability may mean different things to different people.

 

Some people refer to

· Enterprise traceability which proves alignment to business goals

· End-to-end traceability to business requirements and processes

· A traceability matrix, the mapping of systems back to capabilities or of system functions back to operational activities

· Requirements traceability which assists in quality solutions that meets the business needs

· Traceability between requirements and TOGAF artifacts

· Traceability across artifacts

· Traceability of services to business processes and architecture

· Traceability from application to business function to data entity

· Traceability between a technical component and a business goal

· Traceability of security-related architecture decisions

· Traceability of IT costs

· Traceability to tests scripts

· Traceability between artifacts from business and IT strategy to solution development and delivery

· Traceability from the initial design phase through to deployment

· And probably more

 

The TOGAF 9.1 specification rarely refers to traceability and the only sections where the concept is used are in the various architecture domains where we should document a requirements traceability report or traceability from application to business function to data entity.

The most relevant section is probably where in the classes of architecture engagement it says:

“Using the traceability between IT and business inherent in enterprise architecture, it is possible to evaluate the IT portfolio against operational performance data and business needs (e.g., cost, functionality, availability, responsiveness) to determine areas where misalignment is occurring and change needs to take place.”

And how do we define and document Traceability from an end user or stakeholder perspective? The best approach would probably to use a tool which would render a view like in this diagram:

image

 

In this diagram, we show the relationships between the components from the four architecture domains. Changing one of the components would allow doing an impact analysis.

Components may have different meanings as illustrated in the next diagram:

 

image

Using the TOGAF 9.1 framework, we would use concepts of the Metamodel. The core metamodel entities show the purpose of each entity and the key relationships that support architectural traceability as stipulated in the section 34.2.1 Core Content Metamodel Concepts.

So now, how do we build that traceability? This is going to happen along the various ADM cycles that an enterprise will support. It is going to be quite a long process depending on the complexity, the size and the various locations where the business operates.

 

There may be five different ways to build that traceability:

· Manually using an office product

· With an enterprise architecture tool not linked to the TOGAF 9.1 framework

· With an enterprise architecture tool using the TOGAF 9.1 artifacts

· With an enterprise architecture tool using ArchiMate 2.0

· Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

 

1. Manually using an office product

You will probably document your architecture with the use of word processing, spread sheets and diagramming tools and store these documents in a file structure on a file server, ideally using some form of content management system.

Individually these tools are great but collectively they fall short in forming a cohesive picture of the requirements and constraints of a system or an enterprise. The links between these deliverables soon becomes non manageable and in the long term impact analysis of any change will become quite impossible. Information will be hard to find and to trace from requirements all the way back to the business goal that drives it. This is particularly difficult to achieve when requirements are stored in spread sheets and use cases and business goals are contained in separate documents. Other issues such as maintenance and consistency would have to be considered.

clip_image006

 

2. With an enterprise architecture tool not linked to the TOGAF 9.1 framework

Many enterprise architecture tools or suites provide different techniques to support traceability but do not really describe how things work and focus mainly on describing requirements traceability. In the following example, we use a traceability matrix between user requirements and functional specifications, use cases, components, software artifacts, test cases, business processes, design specifications and more.

Mapping the requirements to use cases and other information can be very labor-intensive.

clip_image008

Some tools also allow for the creation of relationships between the various layers using grids or allowing the user to create the relationships by dragging lines between elements.

Below is an example of what traceability would look like in an enterprise architecture tool after some time. That enterprise architecture ensures appropriate traceability from business architecture to the other allied architectures.

 

clip_image010

 

3. With an enterprise architecture tool using the TOGAF 9.1 artifacts

The TOGAF 9.1 core metamodel provides a minimum set of architectural content to support traceability across artifacts. Usually we use catalogs, matrices and diagrams to build traceability independently of dragging lines between elements (except possibly for the diagrams). Using catalogs and matrices are activities which may be assigned to various stakeholders in the organisation and theoretically can sometimes hide the complexity associated with an enterprise architecture tool.

 

image

Using artifacts creates traceability. As an example coming from the specification; “A Business Footprint diagram provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified”. There are other artifacts which also describe other traceability: Data Migration Diagram and Networked Computing/Hardware Diagram.

 

4. With an enterprise architecture tool using ArchiMate 2.0

Another possibility could be the use of the ArchiMate standard from The Open Group. Some of the that traceability could also be achievable in some way using BPMN and UML for specific domains such as process details in Business Architecture or building the bridge between Enterprise Architecture and Software architecture.

With ArchiMate 2.0 we can define the end to end traceability and produce several viewpoints such as the Layered Viewpoint which shows several layers and aspects of an enterprise architecture in a single diagram. Elements are modelled in five different layers when displaying the enterprise architecture; these are then linked with each other using relationships. We differentiate between the following layers and extensions:

· Business layer

· Application layer

· Technology layer

· Motivation extension

· Implementation and migration extension

The example from the specification below documents the various architecture layers.

clip_image014

As you will notice, this ArchiMate 2.0 viewpoint looks quite similar to the TOGAF 9.1 Business Footprint Diagram which provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified.

Another example could be the description of the traceability among business goals, technical capabilities, business benefits and metrics. The key point about the motivation extension is to work with the requirement object.

Using the motivation viewpoint from the specification as a reference (motivation extension), you could define business benefits / expectations within the business goal object, and then define sub-goals as KPIs to measure the benefits of the plan and list all of the identified requirements of the project / program. Finally, you could link these requirements with either application or infrastructure service object representing software or technical capabilities. (Partial example below).

 

clip_image016

 

One of the common questions I have recently received from various enterprise architects is “Now that I know TOGAF and ArchiMate… how should I model my enterprise? Should I use the TOGAF 9.1 artifacts to create that traceability? Should I use ArchiMate 2.0? Should I use both? Should I forget the artifacts…”. These are good questions and I’m afraid that there is not a single answer.

What I know is that if I select an enterprise architecture tool supporting both TOGAF 9.1 and ArchiMate 2.0, I would like to be able to be able to have a full synchronization. If I model a few ArchiMate models I would like my TOGAF 9.1 artifacts to be created at the same time (catalogs and matrices) and if I create artifacts from the taxonomy, I would like my ArchiMate models also to be created.

Unfortunately I do not know the current level of tools maturity and whether tools vendors provide that synchronization. This would obviously require some investigation and should be one of the key criteria if you were currently looking for a product supporting both standards.

 

5. Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository

This other possibility requires that you have an up to date Configuration Management Database and that you developed an interface with your Architecture Repository, your enterprise architecture tool. If you are able to replicate the relationships between the infrastructure components and applications (CIs) into your enterprise architecture tool that would partially create your traceability.

If I summarise the various choices to build that enterprise architecture traceability, I potentially have three main possibilities:

 

image

 

Achieving traceability within an Enterprise Architecture is key because the architecture needs to be understood by all participants and not just by technical people.  It helps to incorporate the enterprise architecture efforts into the rest of the organization and it takes it to the board room (or at least the CIO’s office) where it belongs.

· Describe your traceability from your Enterprise Architecture to the system development and project documentation.

· Review that traceability periodically, making sure that it is up to date, and produce analytics out of it.

If a development team is looking for a tool that can help them document, and provide end to end traceability throughout the life cycle EA is the way to go Make sure you use the right standard and platform. Finally, communicate and present to your stakeholders the results of your effort.

6 years, 1 month ago

Don’t Get Distracted by the Document

This may seem like an odd blog coming from a company that is so deliverable focused, but it isn’t. A design document is not just a document, but a powerful tool for figuring out an architecture. However, it is easy to get caught up in the “task” of completing the design document and lose focus […]

6 years, 4 months ago

Management Information for Managing Innovation

Management information is not particular difficult to produce, it is difficult to make use of. Management information can be produced in quite a few ways and supported by quite a few methods, but too much management information will eventually clutter the line of sight of the decision makers and as such work against holistic management. […]

9 years, 7 months ago

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.