Unified Repository for Enterprise Architecture Management
My story is not for everyone. In the sense that the topic is not HYIP. But those who are in the subject, I hope, will be interesting. It (history) is based on real experience of recent years. I will talk about one of the options - from my point of view, effective - managing a complex architectural landscape.
What I mean by “complex”: these are several hundred business applications with a rather impressive dispersion of attributes — technology, heterogeneity of functionality, connectivity with other applications, criticality, age, size, and so on. Add to this the dynamics, because the landscape is constantly changing dozens of internal and external teams. In other words - the most inveterate, or, in a steady jargon, "bloody" enterprise.
It is obvious that in this boiling cauldron every new initiative on change began with a search: where and what to do, how to determine the sufficiency and the need for change. That is, the analysis was conducted. And since the boiler is large and the degree of change is high, the analysis, and it should be of high quality, lasted for months. But thoroughness did not guarantee 100% quality, since in the same clearing as your initiative, others could be pushed, making changes unforeseen by you.
Someone might say that this is the usual picture for a “bloody” enterprise. Whether the Agile-team deal with the sole owner of the product. Everything is taken into account, and the team knows everything. I will not argue. In many ways, this is true. But on the ragged patchwork landscape of independent teams can not be built. And really large tasks cannot be solved by one team. Yes, and in any methodology should be a reasonable level of order.
')
It is with the establishment of order that we began. This resulted in the creation of a single architectural repository. Let's start with his meta-model. In my opinion, such changes should always begin with the development of a meta-model. This is the best way to explain to interested parties and, most importantly, to ourselves what the new repository can provide. The meta-model will show how your goals fall on the capabilities of the systems where the repository will be implemented. When developing it, the easiest way is to look at the documents that are already in your company. Examine your experience. Look at the vanilla models of various vendors. If it is very serious, then read the GOST, for example, GOST 57100 (ISO 42010).
To begin with, include only the most necessary things in the meta-model, since it is better to start with a simple one. Then, if it turns out that such a model is not enough, then it will not be difficult to develop it. Moreover, the development will be conscious. That is, here the most correct approach is iterative. Start with a small piece of architecture. See how your model handles it. Is it enough elements, links and attributes for the goals and then make a decision about its development.
We approached the meta-model purely utilitarian. Three goals were identified as promising:
The model was based on Togaf ideas. It has several layers and represents two parts of the repository: Current and Solution. "Current" today in a simplified form presented in the figure.
Solution basically follows the “Current” structure, but has some peculiarities.
Although the model is still fairly simple, the first option was much simpler. It was only an Application layer. Then the repository was replenished with components, then with business objects and a business layer.
From time to time, we feel the consequences of the brevity of the model, but for us it’s much more important than its complexity, but the zone of the architecture covered by the repository and the relevance of the information in the repository. So, it seems, we found that middle spot when there is enough strength to maintain relevant information in the repository and at the same time the level of detail is useful and sufficient for analyzing the architecture and creating solutions for initiatives.
Our repository is based on Sparx Enterprise Architect: almost all the opportunities provided by this system for customizing the solution were used - its own meta-model (MDG technology) supported by thousands of lines of Java and Javascript code is used. Of course, customization leads to the need for independent development and support, but we were ready for this.
Now a little more detail about what the current state of the repository is.
At the business layer level, the main elements are business services and usage scenarios:
Services:
And usage scenarios:
In our case, usage scenarios detail the business service in the specific conditions of its use. But still, the script is a rather large-granular representation of business functionality.
Application scenarios are automated by applications — this is already the Application Architecture level, where applications are interconnected by information flows:
Streams contain business objects from the Data Architrecture layer:
The basis for the Application Architecture is the Component Architecture, where each application has its own structure in the form of components, and the flows are detailed as the interaction of components through interfaces:
Now look again at the mentioned elements and their interrelations. Everything is very simple, but it allows to describe the architecture of a large bank at a sufficient level. After several years of work, nearly ten thousand architectural elements have accumulated in the repository, between which several tens of thousands of links have been formed. And this is only the Current Architecture.
We turn to the second paragraph of the above objectives. We need to create a Solution Architecture for initiatives of various sizes, implemented by various methodologies, including Agile.
The solution is described for each architecture layer. The Solution meta-model of the repository part basically repeats the Current structure, but it has differences. For example, the attribute set intersects only partially. Plus, the elements and links from the Solution part have a set of attributes necessary to describe the solution.
Let's walk through all four layers of the solution.
Business architecture contains two kinds of elements. These are large Use Cases, which are implemented in the project, and more detailed Requirements for waterfall projects or User Stories in the case of Agile initiatives. Moreover, Use Cases must have their own mirror in the Current section. At the same time, Requirements and User Stories are elements of the Solution parts only and have no idea in the Current section. Another important detail: the Sparx repository is not a master system for them. They are exported from other systems.
Requirements and User Stories are mapped to the applications responsible for them.
The remaining Solution Architecture layers have diagrams similar to Current Architecture:
The color gamut of elements and connections. The Solution Architecture conveys a view of architectural changes. The description of changes can be entered both in the corresponding attributes of elements and links, and in those attached to Notes elements.
Based on this data, the corresponding parts of the architectural document are generated.
Although, as practice shows, diagrams are the most popular. They are used during discussions with Enterprise-architects, development teams, vendors and on the Architectural Committee.
What is most remarkable, by virtue of the “uniqueness” of the repository, all the elements and links used in the diagrams are documented and uniformly understood by all participants in the discussions. Therefore, initially all participants are on the same wavelength.
Another outstanding moment. A description of the Solution architecture is sufficient to update the current landscape. Thus, upon the release of the solution in production, architectural changes using scripts are transferred from the Solution part to the Current part.
Thanks to this relationship, the repository remains relevant despite ongoing initiatives to change the landscape.
A repository with such a significant number of elements and links, in which dozens of users work, must be maintained in an adequate state. For example, all required attributes must be filled in; communication between elements must be of a certain kind. Moreover, the state of the Application and Component architectures must correspond to one another, since they represent the same applications, but with varying degrees of detail.
Of course, user training plays an important role. But this is extremely small. To err is human. We mitigated this problem with Java and JavaScript code. Every night, according to the schedule, scripts are launched that greatly facilitate our lives:
Comparing the two states - the present day and that “prehistoric” period - one can definitely note that the requirements for architects have increased. The entry threshold for any person who, for one reason or another, needs an analysis of the architecture, has grown.
It is extremely important that the people responsible for maintaining the repository spend a lot of time on it and, in our case, should be able to develop the code.
Returning to the meta-model of the repository, I want to note that within the framework of a simple model it is very difficult to bring together the opinions of many interested parties, and it is even more difficult to stay with it for a long time. And any changes in the meta-model should be reflected in one way or another in the automation scripts.
On the other hand, the analysis of architecture and design solutions have become easier and much shorter. The quality of Solution-architecture has increased by an order. The solution has become much more detailed and always remains consistent. In the work of the architect, routine operations related to the execution of documentation are now minimized, with the need to keep it up to date. The architect is really engaged in creativity.
And finally, a few words about the tool that we used to implement the repository, about Sparx Enterprise Architect. From my point of view, he has an outstanding price / quality ratio. Of course, this is mainly due to its low price, but almost all the functionality we need is present.
What we lack is a variety of interactive views on the data in the architectural repository. After all, a qualitative analysis without them is extremely difficult. We started with simple SQL queries directly to the Sparx database. But then they solved this problem by self-development. In addition to Sparx itself, we look at the repository through a custom web application, where the most popular views are presented in tabular form with the ability to filter, sort and trace between them by selected values:
What I mean by “complex”: these are several hundred business applications with a rather impressive dispersion of attributes — technology, heterogeneity of functionality, connectivity with other applications, criticality, age, size, and so on. Add to this the dynamics, because the landscape is constantly changing dozens of internal and external teams. In other words - the most inveterate, or, in a steady jargon, "bloody" enterprise.
It is obvious that in this boiling cauldron every new initiative on change began with a search: where and what to do, how to determine the sufficiency and the need for change. That is, the analysis was conducted. And since the boiler is large and the degree of change is high, the analysis, and it should be of high quality, lasted for months. But thoroughness did not guarantee 100% quality, since in the same clearing as your initiative, others could be pushed, making changes unforeseen by you.
Someone might say that this is the usual picture for a “bloody” enterprise. Whether the Agile-team deal with the sole owner of the product. Everything is taken into account, and the team knows everything. I will not argue. In many ways, this is true. But on the ragged patchwork landscape of independent teams can not be built. And really large tasks cannot be solved by one team. Yes, and in any methodology should be a reasonable level of order.
')
Unified Architectural Repository
It is with the establishment of order that we began. This resulted in the creation of a single architectural repository. Let's start with his meta-model. In my opinion, such changes should always begin with the development of a meta-model. This is the best way to explain to interested parties and, most importantly, to ourselves what the new repository can provide. The meta-model will show how your goals fall on the capabilities of the systems where the repository will be implemented. When developing it, the easiest way is to look at the documents that are already in your company. Examine your experience. Look at the vanilla models of various vendors. If it is very serious, then read the GOST, for example, GOST 57100 (ISO 42010).
To begin with, include only the most necessary things in the meta-model, since it is better to start with a simple one. Then, if it turns out that such a model is not enough, then it will not be difficult to develop it. Moreover, the development will be conscious. That is, here the most correct approach is iterative. Start with a small piece of architecture. See how your model handles it. Is it enough elements, links and attributes for the goals and then make a decision about its development.
We approached the meta-model purely utilitarian. Three goals were identified as promising:
- Have a description of the current architectural landscape.
- Based on the current landscape, be able to create Solution-architecture for changes.
- Keep the repository up to date.
The model was based on Togaf ideas. It has several layers and represents two parts of the repository: Current and Solution. "Current" today in a simplified form presented in the figure.
Solution basically follows the “Current” structure, but has some peculiarities.
Although the model is still fairly simple, the first option was much simpler. It was only an Application layer. Then the repository was replenished with components, then with business objects and a business layer.
From time to time, we feel the consequences of the brevity of the model, but for us it’s much more important than its complexity, but the zone of the architecture covered by the repository and the relevance of the information in the repository. So, it seems, we found that middle spot when there is enough strength to maintain relevant information in the repository and at the same time the level of detail is useful and sufficient for analyzing the architecture and creating solutions for initiatives.
Our repository is based on Sparx Enterprise Architect: almost all the opportunities provided by this system for customizing the solution were used - its own meta-model (MDG technology) supported by thousands of lines of Java and Javascript code is used. Of course, customization leads to the need for independent development and support, but we were ready for this.
Current Architecture
Now a little more detail about what the current state of the repository is.
At the business layer level, the main elements are business services and usage scenarios:
Services:
And usage scenarios:
In our case, usage scenarios detail the business service in the specific conditions of its use. But still, the script is a rather large-granular representation of business functionality.
Application scenarios are automated by applications — this is already the Application Architecture level, where applications are interconnected by information flows:
Streams contain business objects from the Data Architrecture layer:
The basis for the Application Architecture is the Component Architecture, where each application has its own structure in the form of components, and the flows are detailed as the interaction of components through interfaces:
Now look again at the mentioned elements and their interrelations. Everything is very simple, but it allows to describe the architecture of a large bank at a sufficient level. After several years of work, nearly ten thousand architectural elements have accumulated in the repository, between which several tens of thousands of links have been formed. And this is only the Current Architecture.
Solution Architecture
We turn to the second paragraph of the above objectives. We need to create a Solution Architecture for initiatives of various sizes, implemented by various methodologies, including Agile.
The solution is described for each architecture layer. The Solution meta-model of the repository part basically repeats the Current structure, but it has differences. For example, the attribute set intersects only partially. Plus, the elements and links from the Solution part have a set of attributes necessary to describe the solution.
Let's walk through all four layers of the solution.
Business architecture contains two kinds of elements. These are large Use Cases, which are implemented in the project, and more detailed Requirements for waterfall projects or User Stories in the case of Agile initiatives. Moreover, Use Cases must have their own mirror in the Current section. At the same time, Requirements and User Stories are elements of the Solution parts only and have no idea in the Current section. Another important detail: the Sparx repository is not a master system for them. They are exported from other systems.
Requirements and User Stories are mapped to the applications responsible for them.
The remaining Solution Architecture layers have diagrams similar to Current Architecture:
The color gamut of elements and connections. The Solution Architecture conveys a view of architectural changes. The description of changes can be entered both in the corresponding attributes of elements and links, and in those attached to Notes elements.
Based on this data, the corresponding parts of the architectural document are generated.
Although, as practice shows, diagrams are the most popular. They are used during discussions with Enterprise-architects, development teams, vendors and on the Architectural Committee.
What is most remarkable, by virtue of the “uniqueness” of the repository, all the elements and links used in the diagrams are documented and uniformly understood by all participants in the discussions. Therefore, initially all participants are on the same wavelength.
 |  |
|---|---|
| When analyzing large initiatives, Solution-architect does not waste time searching for information | Software architect, when studying Solution-architecture, sees elements familiar to him. He understands what this architecture is about. |
Another outstanding moment. A description of the Solution architecture is sufficient to update the current landscape. Thus, upon the release of the solution in production, architectural changes using scripts are transferred from the Solution part to the Current part.
Thanks to this relationship, the repository remains relevant despite ongoing initiatives to change the landscape.
Repository support
A repository with such a significant number of elements and links, in which dozens of users work, must be maintained in an adequate state. For example, all required attributes must be filled in; communication between elements must be of a certain kind. Moreover, the state of the Application and Component architectures must correspond to one another, since they represent the same applications, but with varying degrees of detail.
Of course, user training plays an important role. But this is extremely small. To err is human. We mitigated this problem with Java and JavaScript code. Every night, according to the schedule, scripts are launched that greatly facilitate our lives:
- Check the contents of the repository for compliance with the meta-model. The script either corrects errors itself, or indicates the need for human intervention.
- Generate the contents of the Current Application Architecture based on the Current Component Architecture.
- Generate several types of charts to visualize the contents of the repository.
- Generate Solution Architecture documents for prepared initiatives.
- Upload the repository contents to the bank-wide access to the HTML portal.
- Another advantage of a simple meta-model: thanks to its simplicity, automation scripts are also easier.
findings
Comparing the two states - the present day and that “prehistoric” period - one can definitely note that the requirements for architects have increased. The entry threshold for any person who, for one reason or another, needs an analysis of the architecture, has grown.
It is extremely important that the people responsible for maintaining the repository spend a lot of time on it and, in our case, should be able to develop the code.
Returning to the meta-model of the repository, I want to note that within the framework of a simple model it is very difficult to bring together the opinions of many interested parties, and it is even more difficult to stay with it for a long time. And any changes in the meta-model should be reflected in one way or another in the automation scripts.
On the other hand, the analysis of architecture and design solutions have become easier and much shorter. The quality of Solution-architecture has increased by an order. The solution has become much more detailed and always remains consistent. In the work of the architect, routine operations related to the execution of documentation are now minimized, with the need to keep it up to date. The architect is really engaged in creativity.
And finally, a few words about the tool that we used to implement the repository, about Sparx Enterprise Architect. From my point of view, he has an outstanding price / quality ratio. Of course, this is mainly due to its low price, but almost all the functionality we need is present.
What we lack is a variety of interactive views on the data in the architectural repository. After all, a qualitative analysis without them is extremely difficult. We started with simple SQL queries directly to the Sparx database. But then they solved this problem by self-development. In addition to Sparx itself, we look at the repository through a custom web application, where the most popular views are presented in tabular form with the ability to filter, sort and trace between them by selected values:
Source: https://habr.com/ru/post/339402/
All Articles