Some clients think that buying software alone solves all their problems and that professional architecture tools are just ‘Visio on steroids’, which is a misconception that seriously can put the enterprise architecture implementation program into danger (for more details on the different types on architecture tools you might want to have a look at the tool selection articles—part 1 and part 2).

Enterprise Architecture Implementation

A better approach to bringing in architecture tools is to treat this program as an enterprise application implementation that is driven by the introduction of a new capability for the organization. This is obviously a larger effort that needs to be led by the business and not by IT. Doing it the right way will lay the foundation for process improvements, system implementations, business/digital transformations, and regulatory compliance.

This article covers the implementation of the architecture tools. A separate article will cover the necessary EA capabilities that will be supported by the tools, which then can be used for maturity assessments and progression of the internal capability build.

The graphic below shows the architecture tool implementation approach in an overview:

Architecture tool implementation approach

STRATEGY

This work stream (light green in the graphic above) aims to find the proper place of the program within other initiatives and manage it. In the Program Strategy phase it looks at the functional scope of the program (e.g., visualization of processes and where risk and controls will ensure regular compliance on the ‘who-does-what-when-where’ level, typically depicted in BPMN diagrams), and also identifies the ‘sources of truth’ for information, as well as where the architecture tool becomes the main source of information.
This will then also determine how the program will interact with other programs and/or business-as-usual org units that are responsible for systems, as well as the necessary IT/development support (and standards) that are needed to create integrations shown in blue at the bottom of the graphic.

The next step then is to define and formally describe the objectives of the program over multiple releases, as well as the KPIs to measure success, and identify where they come from. This, and the identification of stakeholder information needs, sets the foundation for the development of reports and real-time dashboards in the Visibility phase that support the management of the program.
All artifacts will be done in a Solution Architecture database, which will be extended in other work packages, and serves as the ‘meta’ information source that will be used when interacting with other entities.

At the end of this phase the foundation for stakeholder reporting and visibility is in place.

GOVERNANCE

A second ‘housekeeping’ item is to define the governance that applies to the program (dark green in the graphic above). It typically is set in four work packages that interact with other work packages and all designs are developed in the Solution Architecture database:

  • Process Governance: the definition and documentation of the processes that users, workflow participants, admins, and stakeholders do. These cover processes such as the creation or import of models, reviews and approvals, or the management and operations of technical interfaces that will be created with other systems. In addition to these policies and compliance requirements, such as the level of detail, or the frequency of architecture artifact reviews/certifications will be developed in this step.
    Typically the models created in this phase consist of one high-level Value Chain Diagram with assigned BPMN processes underneath, which will include the business steps, roles, applications, etc. – the ‘who does what when where’ level processes of the program.
  • Organizational Governance: Based on the defined processes, roles are identified, and permissions and privileges will be defined and administered in the tools. The main artifact for this is a license/permission/privilege matrix that includes every role.
    This work package also defines the organizational structure that will run the tools in production, such as a Center of Excellence (CoE), a standards group, or an Architecture Review Board (ARB).
  • Training & Enablement: based on the process and role definition the skills and enablement needs will be determined and a curriculum be built for each role. This not only includes the formal training, but also additional support measures.
    Based on this design, the training and support material will be built and delivered.
  • Organization Setup: In this work package the identified org units will be stood up, candidates identified and selected, and the initial meetings supported by the program management until the org units are self-sufficient in their operations and planning/management.

At the end of this phase the “rules of engagement” are defined, the needed org units/teams stood up, and users are trained in the use and administration of all systems used in the program.

TECHNOLOGY

This work stream (dark blue) is typically the only one that clients think about when it comes to the implementation of an architecture tool. It is typically divided into three work packages:

  • Tool Provisioning & Base Setup aims for making the tools available to the program. Depending on the hosting (cloud or on-premise) this will include different steps and participants, but typical activities include the setup of single-sign-on, connections to the network, integration with email servers for notifications, etc. At the end of this activity the tool vendor “hands over the keys” to the tool, and the program takes over responsibility for the tool, while the vendor and/or the IT organization manages the technical aspects of the tool, such as backups, user group creation, etc.
  • Technical Governance determines the configuration of the tool and the underlying method decisions. This includes the creation of data models and interface matrices (to other systems), as well as a meta model that shows the levels and views, as well as the chosen artifacts on their intersections. These artifacts (typically models) are defined by their notations, objects, attributes, etc. This work package also includes the database setup and structures within each database.
    The data models typically are added to the Solution Architecture database, while the meta model is created in a Configuration database. This allows the creation of the tool configuration files (filter and template in the case of ARIS) automatically by running a wizard on the Configuration DB which saves the time of the manual configuration of each item.

It also facilitates the workshops for the data model and meta model design, and gives stakeholders a first glimpse of how the new tool will be used in other solutions.

  • The last sub-work package of Integration, Reporting & Automation picks up the deliverables of the Strategy and Governance phases and includes the creation of scripts for technical integration purposes, visibility reports, and the automation of (governance) workflows within the architecture tool stack.
    While doing this leading IT practices, such as a defined development approach, or the use of multiple environments for development, test, and production should be considered – stay away from implementation partners who see this development as ‘one offs’ that do not have to follow these practices.

At the end of this phase all tools in the program are stood up, configured and ready to use.

CONTENT CREATION

The last step in the implementation (light blue) is the creation and import of existing content and/or reference content from standards organizations, such as APQC into the Content (Work) database. Existing content might exist in various formats—Excel, Visio, *.bpmn files, etc.—and need to be imported into the tool. This can be a larger effort, since the main work is not initial technical import (this is typically done by the tools well), but the normalization and integration of the content into existing hierarchies—like the other topics above this will be discussed in another article later.

Another part of this work stream is the import of reference data from upstream systems, using the interface scripts from the Technology work package. This data typically comes into the tool as catalogs and they might have to be rationalized and other imported content, such as processes, need to be reviewed to see if they used the correct content from the system of truth of if there are discrepancies and or needs for consolidation of objects to ensure consistency of the database and also the content structure.

At the end of this phase the architecture tool is ready for a roll-out to a wider audience.

HOW TO SEQUENCE THE ENTERPRISE ARCHITECTURE IMPLEMENTATION?

The color coding in the graphic above shows the type of roles that do the four work package – program management is working on the Strategy, business consultants support the governance design, technical folks take care of the technology and integration/reporting, while a first set of end users will import existing content and create initial structures within the Content/Work database.

However, not all activities take place at the same time. My suggestion for the sequencing is:

  1. Program strategy, and tool provisioning & setup (assuming the tool selection is already done)
  2. Definition of process and organizational governance, as well as technical governance
  3. Build of integration, reporting & automation and visibility
  4. (In parallel to 3) Stand-up of the org units, and training design and delivery to the initial first end users, who will become power users when the tools roll out with a wider audience.
  5. Import of existing and reference content
  • Enterprise Architecture Implementation - Step 1