TOGAF documentation mapping

Question

According to TOGAF specification, the main domains / division of concerns are:

• Business Architecture
• Data Architecture
• Application Architecture
• Technology Architecture

According to the specification, the Enterprise Repository should hold all information.

I have this information:

• How it works the company in terms of business model
• How it works the application in terms of functional features
• How the application is implemented and deployed

How can I map this data according to the TOGAF big picture?

• App architecture description --> Architecture Landscape ?
• App components description --> Solutions Repository ?
• App functional description --> Architecture Capability ?
• App deployment info --> ¿?
• Business model --> ¿?

---

Update 08/11/2018

Some questions I have:

• Where can I put company info like company structure, people, teams, etc?
• Where can I put business info like products and services offered by company, how pricing is calculated? what it means "X thing" for the business?
• Where should I put ongoing assessments? and where should I put once it's put in production?
• Where should I put a general glossary of terms?
• Where should I put development guides? like list of environments, IPs, delivery workflow, jira workflow, etc?
• Where should I put service API definitions?

Answer 1

You are trying to mix Solution Architecture and Enterprise Architecture, that's probably why it seems confusing.

TOGAF is about enterprise architecture - big picture stuff, as you correctly pointed out. Information about a concrete app on the other hand is more of a solution architecture concern. Of course, one could argue that you can describe enterprise architecture as detailed as you need, but that's not the point.

Answering your original question, though: it seems like app information (architecture description, components description, functional description) you have should be stored in Architecture Repository as Solution Building Blocks. I'd recommend addressing them as part of Baseline Application Architecture and Baseline Technology Architecture description, during Phase C and Phase D.

Then again, you should first carefully consider wether you really need level of detail this high.

P.S. if you provide a bit more context on what you are trying to achieve, I'd probably be able to give you more specific advice

Update 11/11/2018

Where can I put company info like company structure, people, teams, etc?

It depends. Company structure should be stored in Baseline/Target Business Architecture as part of Organization structure model. Here's a definition from TOGAF:

"Organization structure: document the organization structure, identifying business locations and relating them to organizational units."

It is also one of the inputs - Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 of TOGAF spec).

Where can I put business info like products and services offered by company, how pricing is calculated? what it means "X thing" for the business?

It is also a part of Business Architecture, here's a whole list from TOGAF spec:

• Organization structure - identifying business locations and relating them to organizational units
• Business goals and objectives - for the enterprise and each organizational unit
• Business functions - a detailed, recursive step involving successive decomposition of major functional areas into sub-functions
• Business services - the services that the enterprise and each enterprise unit provides to its customers, both internally and externally
• Business processes, including measures and deliverables
• Business roles, including development and modification of skills requirements
• Business data model
• Correlation of organization and functions - relate business functions to organizational units in the form of a matrix report

Where should I put ongoing assessments? and where should I put once it's put in production?

There's a standard pattern in TOGAF:

1. Assess current situation and write it down as Baseline Architecture
2. Create a vision and write it down as Target Architecture
3. Work towards Target Architecure and update Baseline Architecture as you go

So, in the end, your baseline should become equal to target and now it's your new baseline for the next ADM cycle.

Where should I put a general glossary of terms?

It's usually done as soon as possible during tailoring TOGAF to your enterprise - Preliminary Phase of the ADM cycle (see Part IV, 36.2.21 of TOGAF spec).

Where should I put development guides? like list of environments, IPs, delivery workflow, jira workflow, etc?

Developments guides, jira workflow and other project management stuff is not usually of a direct concern of TOGAF. It should be definitely be aware of it, enterprise architect might even consult on this matter. Only one thing comes to mind in terms of project management - roadmaps, they are written down and updated as needed during virtually all the phases.

Environments, IPs and other infrastructure information is usually worked on during Phase D, mainly as part of technology architecture models and specifications.

Where should I put service API definitions?

Again, you should carefully consider if you need this level of detail, but it seems appropriate to address it in Phase C (Applications Architecture). One of the steps is defining a model (it's advised by TOGAF to find reference in your industry), which may include API definitions. It's usually enough to address a more abstract Applications Interoperability in terms of the enterprise.

Very important point: TOGAF is just a framework, you can tailor it as you see fit for your current enterprise, just don't forget to document it. You should also remember that it's not just a set of tools, but also a set of expectations, glossary of terms and guidelines, so a new architect wouldn't need to learn everything from the ground up in each new enterprise he works at. As it always goes - you have to find a proper balance point.