Enterprise Architecture 101: Keep your Architecture Repositories – KISS-S

Viewpoints on Architecture repositories are topics of perennial discussion in digital forums and communities (eg link). Such discussions are the tip of the iceberg, bubbling up some of the frustration over time and energies that Architecture and Design teams spend on evaluating and managing Architecture Repositories. The focus of discussions range from What information to capture and document, to How-to manage the repositories, and includes debates on tools, technologies and platforms to use.

Architecture frameworks like TOGAF have captured the first part of the question well, explaining the need for repositories to operate mature Architecture Capabilities at large enterprises. TOGAF references (link) describe

“An Architecture Repository that allows an enterprise to distinguish between different types of architectural assets that exist at different levels of abstraction in the organization. This Architecture Repository is one part of the wider Enterprise Repository, which provides the capability to link architectural assets to components of the Detailed Design, Deployment, and Service Management Repositories.”

Why don’t organizations just adapt Frameworks like TOGAF that are obviously well documented? Just a couple of reasons why:

• While the documentation in TOGAF is rather extensive, it is also rather generic, and needs to be tailored to meet specific requirements of your organization. Like a Swiss-Army-knife, not all aspects of architectural information may be required or applicable for all organizations. 
• Architecture documentation and processes don’t operate in isolation. They need to exist seamlessly with your enterprise's change management and governance processes. 

In an earlier write-up (link), I highlighted my experiences in establishing and running an Architecture Review Board (ARB). To succeed, the architecture governance had to be embedded with the existing processes, and ways of working.

The same holds true for Architecture Repositories too. Architecture and design teams in large organizations spend a lot of time and energy documenting the current and future state capabilities. The translation of such strategies and ideas into workable solutions - capability realization - is enabled by business funded projects and programs. Large programs also generate a tremendous amount of documentation to adhere to existing governance processes and project management and operational frameworks.  

It is fair to assume that large organizations will have extensive collaboration and team management tools and platforms including enterprise portals, wikis, blogs and even social media tools used by teams across the organization. Therefore, it is important to keep the design of any Architecture Repositories KISS-S. 

Architects should recognize the capabilities of existing organizational tools and platforms, and either extend them to include architectural repositories, or ensure that any additional tool integrates seamlessly with existing platforms. The additional S at the end of the common acronym KISS is to emphasize the 'S'eamless integration and ‘S’earchability of the artifacts in the repository. For example, if your organization uses a Sharepoint based intranet platform, you are better off designing a simple repository and workflow extending that platform. 

Those searching for "Design document for SFDC XYZ program" or "Solution Design template" should be easily discoverable using a simple search on your enterprise’s intranet without having to search for a member of your team who can help find that document. 

Bottomline: All your relevant non-confidential architecture references should be searchable across the enterprise and not 'guarded' behind a firewalled repository. Only then they will serve the purpose: to educate, inform and influence organizational design.