During my last assignments I had the rewarding task to drive the introduction of an enterprise architecture repository (EAR).

Among some skillful and motivated architects we exercised the usual stakeholder assessment, identifying their concerns and influence, setting goals and aligning them with the strategic and tactical goals of the organization.

The scoping part however was less straightforward and far more complex than we had anticipated.

Analyzing the process it appeared that the discussion in fact came down to a set of 10 dimensions that together make up the entire EAR scope.

We applied this knowledge by addressing each of these dimensions individually. This helped us to structure the scoping process and making it less complex and more transparent through a “divide and conquer” approach.

The biggest pitfall in EA is trying to do “it all” – hence scoping is vital. And even if the ultimate ambition is “all” scoping can still help you in setting meaningful phases in order to introduce an EAR incrementally, providing value early in the project.

In this article I would like to discuss each of these 10 scoping dimensions briefly.

1: Enterprise

The organization-scope is the primary consideration. TOGAF and Thomas Erl already propagate to define clearly the “Enterprise” in EA.

It involves the following concerns:

• Does Enterprise comprise the complete organization, or just one or a few business units.
• Does Enterprise also incorporate parent companies (the holding) or siblings (subsidiary companies)?
• Are supply-chain partners (suppliers and/or customers) or other market-parties in scope in an integrated EA?

Setting the enterprise-scope correctly is vital for the chances of success in terms of support and effectiveness of the EAR initiative.

2: Domains

The EAR is most likely to be used primarily by the domain architects. To TOGAF and ArchiMate business-, application/data and technology are the architecture domains. Tailoring allows to adopt or ignore any of those in your EAR. An educated choice should be made here.

Also other domains can be considered in a repository, like security and information architecture domains. Note that domains like these may have overlap with traditional domains. In that case the EAR should take this into account.

3: Models

Multiple modelling techniques may be required to describe your architecture.

In our cases for instance we have deployed ArchiMate, UML and BPML.

Though ArchiMate has the ambition to be a one-fit-for-all UML and BPML do offer additional value – for instance UML for entity / data modelling and BPMN for business process modeling.

Obviously there are many more modelling techniques to consider to be incorporated in the EAR.

4: IT-Development-lifecycle

Looking at a traditional IT lifecycle (Requirements, Architecture, Analysis, Design, Implementation, Testing, Deployment) from an EA point of view it may seem logical to focus on architecture.

However obviously EA is broader. Frameworks like Zachman and TOGAF acknowledge that goals and requirements are important drivers and hence ought to be part of the EAR – which results in potential benefits like business-IT alignment and traceability.

Typical analysis products -like use cases- may be comprised in the repository as well.

Even design and implementation may be part of an EAR in case of Model Driven Architecture (MMD).

5: Time

The content of the EAR is time related. Any artifact has a specific status on a certain moment.

Therefor scoping does have to take the time aspect into account: Will the EAR only contain the baseline (as-is) situation? Or will it comprise future states as well, like the target- and transition architectures. And will history be retained after the baseline is changed e.g. in order to collect data to improve the EA practice? All fair questions to ask.

6: Application

The primary function of the EAR is generally to record the (baseline) architecture.

But additional functions may be provided as well:

• Support of communication means (visualizations) of the content to the stakeholders
• Support for portfolio management and roadmaps (e.g. as supported by ArchiMate platforms)
• Support for project/solution-architectures (in case organizations have not yet adopted “working-under -architecture” completely)
• Support for sandboxes for informal usage like training or sketching

7: Users

Domain architects will be the most likely users of the EAR. Though other stakeholders may be granted access to the repository as well. It should be considered which business roles ought to have access to what particular EAR content and with what particular rights.

Notice there may be a close relation here with dimensions 4: IT Development Life cycle and 6: Application.

8: Tools

Ideally the repository the based on one single product. Think of one of a number of specialized EAR-products from for instance IBM, Mega, Sparx, Troux, Avolution, BiZZdesign, OpenText, SAP and CaseWise. The advantages of a using single product are obvious and prevention of integration issues is key.

However the scope of EAR tooling may be broader. A tools for instance have the capability to publish information through a Wiki. The Wiki-environment could be considered as part of the repository.

Also there may be tools in place that are positioned to contain information that may be considered as EA content. Think for instance of the business processes that are modeled and executed in a BPMS-tool.

Using multiple tools may be a valid choice from the organizations perspective, but usually come with a cost in terms of increased complexity and integration issues of the content over different products.

9. Abstraction

The content of the EAR may be at different abstraction levels.

In general architecture components are first described at the highest level and along the way detailed out using aggregations or part-of constructions. It ought to be decided what the detail-level is that the EAR can contain in order to prevent too much detailing and overlap with detailed design of the development teams.

Another type of abstraction is the architecture meta model. Such a model usually describes the principles and guidelines on architectural modeling: Which components and relations are allowed and which data should be recorded?

The meta-model may -or may not- be incorporated in the EAR as well.

10: Context

It may be required to add contextual data in the EAR. Think of public reference architectures  and architectural information about B2B partners and external systems. Some valid use cases are modeling of B2B-interfaces and to adopt and extend certain industry standards.

As context information is virtually unlimited the selection should be done with care.

Note that the dimensions are not strictly mutually independent: some may have inter-dependencies or some overlap. Evaluating them individually though may provide assistance in terms of complexity reduction.

Hence this article should be considered more of a practical assistance in effectively defining an EAR than a theoretical lecture.

I hope it may be beneficial to you too.