March 8, 2020

How to Get the Most from an Enterprise Architecture Repository

If you don’t yet have an Enterprise Architecture (EA) application for your practice, you might face resistance to investment. It is no longer possible to keep up with the pace of today’s digital market with two-dimensional tools like spreadsheets and shared drives. Both the current and future state models of the enterprise are changing at least monthly, if not weekly. Without the right tool, you’ll end up spending more time updating documentation than designing. Solution, application, data, security, and infrastructure architects all need the same view of the enterprise IT landscape to coordinate their different responsibilities. The current and future state models of the enterprise (as well as design patterns, reference architectures, and standards) are maintained in an Enterprise Architecture repository. Changes made by these teams of architects must now be captured almost in real-time. A fit-for-purpose software application is the only way to avoid delays for rework caused by miscommunication. In organizations that are more dollar- than value-driven, building the business case might take some extra work but it is possible. Once you have the software in hand you’ll want to get your repository up and running quickly to demonstrate the value to your stakeholders.

Communicating the Value of a Repository

The first thing management will ask when you suggest bringing an EA repository application to your organization, is “why”. “What will this application do that we can’t already do? Why can’t you just use SharePoint?” We start with the following attributes when describing the value to the organization:

Single authority and source for all architectural artifacts and definitions within the organization
Designated subject matter experts (SMEs) maintain common or shared artifacts
Promote a collaborative and communication-rich environment
Easier to ensure organizational standards are habitually met
Enforce a single modeling language (such as Archimate 2.0)
Ensure a consistent diagramming practice
Faster identification of integration points between different business, application, data, and technology components
Easier to create solution blueprints
Less time spent researching the current state (Translation: less time spent in meetings and more time architecting)
Improved knowledge management and lower risk due to tribal knowledge
Enable EA governance with low initial investment and high return

Each of these attributes applies to any platform that supports both EA frameworks and architecture modeling. (Platforms like LeanIX that focus only on EA and not solution modeling will not achieve all of these benefits.). To further streamline your case to management, consider SPARX Enterprise Architect*. SPARX EA is less pricey than comparable platforms and its “out-of-the-box” packages can speed up implementation.

Implementing a Successful Repository

Whichever platform you select, ensure that your implementation allows access by multiple users at the same time. For example, with SPARX EA, use the multi-user MSSQL backend implementation rather than the stand-alone file version. Some organizations failed in their SPARX implementation because they could only have one person editing at a time. This destroyed their ability to maintain an accurate picture of the organization and encouraged their architects to go back to the old way of doing things.

When designing your repository, our best practice is to take the “bottom-up” approach. Build the “technology”, “application”, “data” and “business” architecture components first. In many situations, you are gathering information about the current state as you build it into your system. Information about technology and applications is often easier to collect than data and business. Understanding of data and business architecture is often less mature or well-documented. Even before the components are fully populated, you can start using them as instances in different blocks that form systems. For example:

Business Architecture

Create Process blocks
Define Services using Process blocks
Build Functions using the Services
Using the Functions create Attributes for a Business Unit
Use multiple units to create the business itself

Required Model Elements

Current State
Transition State
Future State
Actors within the enterprise
Enterprise Solution Architecture Repository
Vendor Systems (represent external vendors as placeholders within your model)

The Enterprise Architecture current state, transition state, and future state are divided into different architectural domains including integration (containing services) and security (containing standards). The solution architecture contains individual solutions created when building the current state. They are representative of a system or a system component. As a best practice, we create the following diagrams for every solution:

Solution Diagram

Use Case Model Diagram
Components Model
Context Model
System Sequence Diagram

Additional Considerations: People and Process

Use Case Model Diagram
Components Model
Context Model
System Sequence Diagram

Once your EA team has initialized the EA repository, they become the custodians of the repository. The users are the architects modeling within the application. Their day-to-day efforts ensure the ongoing accuracy of the current state. This approach minimizes the total effort needed but requires buy-in from the teams involved. The difficulty of getting buy-in will depend on the structure of your organization. For example, it will be more straightforward if enterprise and solution architects are part of the same team. Regardless of organizational structure, you will need defined responsibilities and processes for use of the repository. These can be supported through different levels of user access to the application. As custodians of the system, the EA team is responsible for ensuring these processes are effective.

If you are interested in making the case to use SPARX in your enterprise and have not used it before, SPARX Systems offers a free 30-day trial*. Thirty days is enough time to build your initial model and socialize it with your stakeholders for their buy-in.

*Sysonex, Inc. is not affiliated with SPARX Systems and does not receive any compensation for this endorsement.

Want to learn more about our ideas and thought leadership, please read the following. If there are any areas of interest from your organization, please feel free to reach out to us.