In a previous post, we started the series Practical TOGAF as a means of showing how architecture frameworks aren’t big scary things. We continue that series here. But before going too far into describing the TOGAF ADM (Architecture Development Model), we should discuss the Repository. In simplest terms, it is the location where all artifacts related to Enterprise Architecture are kept. However, it is important to understand that there are specific characteristics that should be observed. Please note: these are MY opinions, so your mileage may vary.

The diagram at left is a graphic describing the artifacts which belong in the Architecture Repository. This list is by no means exhaustive, instead grouping them by their relationships.

Note that I have coloured the boxes containing Architecture artifacts to match the Archimate modelling language. That way, when we examine architectural diagrams in a later post, it’ll be easy to spot which components are Business, Application or Technology components. I have also chosen to colour the Roadmaps to align with the Motivators component of the Archimate modelling language, because Roadmaps describe the motivations for getting things done !

In my humble opinion, the Architecture Repository should have its home in the larger Enterprise Information Repository. Often, Enterprises will utilize a single tool, called an Enterprise Content Manager (ECM), to collect & curate their business information. While there are many choices of ECM, they should all share some basic attributes. Briefly, these include:

Version Control – the ability to look back through iterations of the artifacts gives the Agile EA the ability to track the changes the artifacts have gone through.

– the ability to look back through iterations of the artifacts gives the the ability to track the changes the artifacts have gone through. Change Control – similar to version control, this attribute refers to who has stewardship over the artifact vs who has viewing rights.

– similar to version control, this attribute refers to who has stewardship over the artifact vs who has viewing rights. Universal Access – the ability for all employees to view the published artifacts gives them greater insight into the direction the Enterprise is going. This allows them to be more collaborative, adding to the value of these artifacts.

– the ability for all employees to view the published artifacts gives them greater insight into the direction the Enterprise is going. This allows them to be more collaborative, adding to the value of these artifacts. HTTP-Based – in my opinion, universal access also implies ubiquitous access. An employee should be able to view the published artifacts in a web-page. Properly curated, portions of the ECM could even be publicly-facing, such as on the open Internet.

– in my opinion, universal access also implies ubiquitous access. An employee should be able to view the published artifacts in a web-page. Properly curated, portions of the ECM could even be publicly-facing, such as on the open Internet. Standards-Based – again my opinion, but the ECM should display and serve the various types of artifacts (diagrams, white-papers, spreadsheets, etc) in either their native form or in HTML format.

– again my opinion, but the ECM should display and serve the various types of artifacts (diagrams, white-papers, spreadsheets, etc) in either their native form or in HTML format. Integrated – the ECM is not a stand-alone tool. So data-sources such as source code repositories, business reporting tools, and even ticketing systems should be able to be served from the ECM.

You might be thinking that this is a lot to ask of an ECM. Fortunately, these are considered “table-stakes” – the minimum standard by which ECM Solution providers measure themselves.

In the next post, we’ll dive into the first couple of entities on the TOGAF ADM, looking at the Preliminary phase, followed by posts about the Business, Application and Technology architecture-development phases.