EA Tool for IT Architect

If the most popular question about the work of architects is “Who are architects and what do they do??”, then the second most popular reason for the failure of architectural practice after “Didn't agree on vision with management” is the lack of a normal tool. This tool means Enterprise Architecture Toolof which there are a huge variety on the market, about the same as the various frameworks and architecture methodologies.

By the way, speaking about frameworks, if the choice is difficult and you don’t come across anything other than TOGAF, I recommend the book “The Practice of Enterprise Architecture” Svyatoslav Kotusev, whom I mentioned in a publication on the topic of architects' skills.

I have been using various tools for many years and for some time I was even selling one of these tools (in my opinion, very successful, with a couple of exceptions), and in this publication I decided to share my previously accumulated experience.

The first and golden rule in choosing a tool, and EA Tool in particular:

Fools with tools are still fools.

Without understanding your work, your needs and its goals, no tools will help you. And even more likely they will do harm, since the purchase of any tool will lead to additional costs, and therefore will increase the level of expectations from the work of the architect. And if, instead of a significant (and as a rule, such tools are not sold in any other way) increase in value from the activities of an architect, management receives a poorly automated bureaucracy, which only slows down the company’s development process, the consequences can be very dire.

Tool Not a magic wand that with one wave will solve all your problems in development speed, increasing productivity, creating a single point of truth, and so on.

Any tool we use, be it a source code repository, a garbage collector, a source code build pipeline, etc., is automation of routine. Due to which we can free up the team’s time for more useful work.

Second The principle of choosing any tool is that if it does not free up time, but creates additional difficulties, it is a bad tool.

When they sell you an EA Tool, they usually call it an architecture management tool. enterprises. It sounds cool, and the presence of the word “management” immediately attracts the attention of management, whose core competency is management. But the tool itself does not control anything, especially an enterprise in which architects perform a supporting function, which is certainly important, but still does not bring money. And the basis of any commercial organization (for which these tools are offered) is making money. It would be more honest to name such products architectural repository. That is, a place for storing objects and artifacts that architects use in their work.

1.Inventory

Perhaps the most important function of the EA Tool is the ability to certify the most important elements of architecture that are subject to change as a result of the architect's work with them.

Which elements need to be certified depends greatly on each specific case. The areas of responsibility of architects can vary greatly from enterprise to enterprise. For example, if the infrastructure is provided as a service, it is unlikely that you want to know the name of each machine, its cluster or IP access to the admin panel. But if you use your own infrastructure or rent it, infrastructure accounting issues will not be idle for you.

Therefore, when choosing an EA Tool, first of all you should think about metamodels:

1. What objects do you want to consider?

2. What do you want to know about them (composition of attributes)?

3. How are they related to other objects?

4. How often does the metamodel need to be changed?

5. What methods of filling the repository are available to you? (manual and/or automatic)

Here's a short list of questions to ask yourself as you begin your journey of choosing an EA Tool.

Of these requirements, the key should be flexibility in customizing the metamodel.

Example metamodelswhich my team and I built for my architectural practice:

Many tools come with a tightly configured metamodel (for example, Archimate) or changing it requires ongoing work on the vendor's side, which means ongoing costs.

Rigidity is not the same as bad, but when choosing a ready-made metamodel, you need to be ready to adjust architectural practice to the underlying logic, which, in my experience, is not always possible, and such a choice leads to the emergence of different bypasswhich in turn contradicts the logic of choosing a tool protected by a metamodel.

2. Methodology

The next important aspect of choosing an EA Tool is methodologyadopted in each specific organization, because the methodology will determine the rules for updating information, set deadlines and impose requirements for the final documentation.

Architects don't just work with a repository of objects separate from the entire organization. The repository serves as a storage place for objects that are retrieved by the architect to be revealed to the world in one form or another.

The most typical representation is diagram a solution that demonstrates interconnected objects of architectural accounting and reflects the essence of the proposed changes, in rare cases demonstrates an existing problem.

But sometimes you need to upload a list of objects with their attributes or even build individual views directly in the repository.

For example, the construction of tree-like hierarchies or node graphs that reflect the decomposition of a complex system into its component parts or show the flow of information through the IT landscape.

In questions methodology you should think about:

1. What artifacts (documents) do we use?

2. What artifacts are we automating?

3. What architectural views do we require?

4. Is it necessary to import back from artifacts into the repository?

5. How difficult is it to adapt the tool to our artifacts?

These questions will help you determine how well the chosen tool meets your methodological requirements and whether it can effectively support your architectural practice.

Choosing the wrong tool can do you a disservice when the artifacts generated by the EA Tool will be modified manually and then discarded as unnecessary. They definitely won’t thank you for such a tool, and you yourself won’t be happy with such automation.

The most striking examples of such automation are government agencies, when the application is first filled out electronically, submitted in paper form, and error correction must be done electronically, based on what is indicated to you on paper.

3. Process

In any organization of human activity, the process exists on its own, regardless of whether analysts have described it or not. This fact must always be taken into account in work, especially when it comes to automating activities, for which, as I wrote above,

When choosing an EA Tool, you need to think very deeply about how working in a new tool will fit into your current design process.

Which steps from this process will you automate? Which ones will you leave behind? and which ones will you implement along with the tool?

For example, in my practice there was a case that, along with the implementation of the tool, all IT assets received a unique ID from the repository. All requests for budget approval for improvements must contain the asset ID. This allowed budget committee members to go to the repository and see what the asset was. If an asset was not in the repository or information about it was insufficient, the request for modification was rejected.

It is extremely naive and dangerous to believe that by implementing the EA Tool you will be able to build a design process that did not previously exist. With a high degree of probability, you will introduce a couple of the same random steps into the great randomness of decision making – how to enter information into the repository, get information from the repository.

WITH process point of view, it is worth thinking about the following questions:

1. What does the current design process look like?

2. What problems are there that require automation?

3. How will the tool help solve problems?

4. How will the process change with the implementation of the tool?

5. Who besides architects will use the tool?

If, after answering these questions, new ones appear, but clarity is not added, you should not approach the issue of choosing a tool. The description needs to be done at least at the level of large blocks or a list of typical problems in the form of use cases.

One of the problems that we recently had to solve was the enormous labor costs of searching for information about the infrastructure on which this or that system is deployed. Each time this had to be done manually, using downloads from several virtualization environments, and then brought together through the heads of several specialists.

In the process of creating a unified infrastructure registry and trying to connect this with systems, a number of problems were automatically discovered in processes related to architecture. And to solve the inventory problem it was even necessary to change the internal regulations of the operation service.

***

The publication covered only the basic aspects of choosing a tool, and still turned out to be quite voluminous. Choosing the right tool can take up a full chapter of a book or dissertation, but I tried to outline the main points here.