I recently had an experience with a CIO organization considering how to begin doing some Enterprise Architecture. First of all, they expressed they did not want to first establish an EA practice, but wanted to do something more practical, like going ahead and selecting an EA tool. Of course, I told them that, in my “humble” opinion, one should first think about what your EA practice is going to be in terms of structure, roles and responsibilities, footprint, etc., before deciding on a tool that could then at some point later be provided to the hypothetical EA practice. In short, this was an anti-pattern for thinking about EA tools, one that has persisted for at least 20 years, as long as I have been training, consulting, and actively practicing EA. 

As important as having a world-class EA tool environment in place that is appropriate to the type, size, and complexity of the organization doing EA, one must not skip the step of explicitly laying out the EA practice and associated charter in order to do something IT shops feel most qualified to do: select and implement solutions. That noted, this underscores a general anti-pattern for solution architecture as well: having a hammer so everything must be a nail! Just as for an EA practice, tools should only be investigated and ultimately procured based on a careful organization analysis for optimum alignment with business strategy and direction. Otherwise, silos of tool capabilities will emerge yielding duplication and persistent gaps in what was actually needed.

In short, “strategic” patience is essential for better synchronizing any decisions about EA tools once EA is more fully understood and a practice is set up with defined scope, roles and responsibilities, and a roadmap for delivering incremental value.

One of the reasons for a more strategic, “city planning” type of thinking for the consideration of EA tools is that the overall architectural landscape must be more fully understood in its current and targeted states. There is no single tool to understand and manage a complex, ever changing landscape, so architects must understand the ecosystem of tools needed for information/content management about the environment. Therefore, decisions about EA modeling tools also need to consider architecture repositories.

Some tools come with their own architecture repository. For others, additional configuration and integration will be required to integrate the modeling tool with one or more databases. Even if a tool comes replete with its own architecture repository, you would most likely want to be able to integrate it with other content management systems, such as ServiceNow and Teams. In addition, there are now apps that specialize in being kind of the “repository of repositories” for organization visual artifacts, such as MID’s smartfacts (smartfacts.com), ideal for the publishing of and collaboration on artifacts created from a panoply of tools.

In addition,  two decision making aspects must also be matured vis-à-vis the selection of EA tools: the business case overall and a supporting analysis of alternatives. EA Principals is working with the Shark Finesse toolset to help build templates for EA practice and tool business cases for different types of organizations in different verticals – in short, there should be more repeatability in the way business cases are done, whether for EA practices/tools or any other investments. Therefore, this is a skill set that Enterprise Architects need to build, along with the associated approach to doing analysis of alternatives or AOAs. On this note, EA Principals has a current tool capability to assist organizations to take structured approaches for AOAs through the use of its Parmenides EIDOS tool suite. However, we see the need to make AOAs something that can be done on a self-service way through an easily accessible mobile app and are working to get this on the market later this year.

In conclusion, making decisions about EA tools brings up the whole topic of decision making overall in an organization and how, for example, an IT department can mature in its competences in the decision support space. Part of this enhanced maturity is knowing when to make a decision about an investment, and a key takeaway of this article is that one should make decisions about EA tools at an appropriate time, not rush to do it before the entire business case can be intelligently laid out.
 

Authored by Dr. Steve Else, Chief Architect & Principal Instructor