When Documenting Your Enterprise Architecture, Value Metadata over Models

Architecture is an inherently visual discipline. When trying to convey a complex, interconnected environment, the picture can truly be worth a thousand words and more. Peruse any enterprise architecture (EA) repository, be it a highly tailored EA tool or a SharePoint document library, and you’ll likely find a multitude of architecture models. These models often form the foundation of the EA team’s efforts to communicate the current and target architectures for the organization.

However, if you were to begin to dig into these repositories in detail, you’d likely find:

• Models that are out of date. Often created as part of a specific planning initiative or major project, the models have not been kept up to date as the environment changes. (Let’s be clear – this is often an issue with IT documentation overall, not just in EA.)
• Models that are inconsistent in format. Architects are always pushing reuse, but they can often fail to apply this to their own approach to modeling. Some teams may have adopted a standard format, be it internal or an industry standard such as ArchiMate, but they are likely also to have older models that were created prior to that standardization.
• Models tailored to a specific audience. Each model is typically skewed towards an intended stakeholder or consumer. This is true whether you use a standard modeling format or a more custom format. Often these models are geared towards IT-centric viewers and not usable when working with business stakeholders.
• Models that are incomplete. Each model is typically created for a specific purpose. As a result, they can be missing details that may not have been relevant at the time they were created but are now important. The details may have been easily available then, but now additional work is required to fill in those gaps.

The problem is that diagramed models, by nature, are not ideal mediums for holding information about your architecture. They are best as communication vehicles for informing, influencing, and shaping the conversation regarding your strategic architecture initiatives—snapshots of your enterprise architecture that are crafted for a specific purpose. As such, they become somewhat transient in nature, and their value diminishes over time.

Why metadata matters
To establish a long-term foundation for your repository, you should instead focus on the underlying metadata for your architecture. This metadata encompasses your business capabilities, processes, applications, infrastructure, data entities, and integrations. This information will be a mixed set of data that can come from multiple sources, including configuration management database (CMDB), asset management repository, spreadsheets, portfolio management tools, EA tools, etc.

A well-managed repository of metadata can be a powerful tool for architecture planning. Business intelligence tools can be used to generate key metrics for the health of the architecture. Models can be created to represent this information, formatted to meet the exact needs of the target audience, but the core data would reside outside the diagrams. The difficult questions are:
1. Where do I store this information?
2. And how do I keep it up to date?

There are several options for storages of the architecture metadata. Many of the leading EA tools are set up to store the information in their proprietary metadata model and have capabilities to integrate to external CMDB and asset management repositories. Lacking a purpose-built vendor tool, many companies also look to deploy custom data marts in order to aggregate the key data.

Wherever the data is stored, keeping it fresh is critical to maximizing its value. Any integrated data from a CMDB or asset management repository should leverage the exiting processes and procedures in those systems to maintain up-to-date data. Often those same processes—change management, for example—can be leveraged for other metadata outside those repositories. Other times, the data will need to be manually maintained by the EA team. This problem can be somewhat simplified by the fact that the requirements for freshness of the architecture data are not high. Data that is accurate within a three- to six-month period is often enough.

The EA team could gain significantly more value if metadata were the core of the architecture repository, as it allows for a broader and more complete view of the environment. Models can flow from this information, created to meet the specific needs of the intended audience, but keep in mind that their value will diminish over time. The underlying metadata offers a more sustainable foundation that can support multiple initiatives and transformations for the business now and in the future.