Architecture and Architects
Relatively long ago, I attended a seminar dedicated to the management of architecture and its control, and all wanted to describe the knowledge gained, since there was a lot of information, and most of it was very useful. I can say that my ideas about architecture have greatly expanded, and the topic turned out to be deeper and wider than I imagined. But this is good, there are starting points that can be worked out independently in the future. So, ending with the lyrics, I want to provide a brief summary on the architecture.
Most developers, most likely, imagine an architecture only as an application to a specific project, i.e. You can often hear from them "software architecture", but this is only a small part of what is included in the general concept. It is conditionally possible to divide the global concept into several parts, from the general to the particular. You can imagine them in the form of a pyramid:
Thus, developers most often talk about the technological architecture of the application.
Business architecture, also known as Enterprise, is a presentation of how to effectively reproduce business goals and strategies by creating, improving and combining key requirements, principles and models for successful business development and achieving goals. Definition taken from the English Wikipedia. Enterprise architects should focus on business needs and analyze data flows, i.e. cover the two indicated points. Solution level architects deal with the technological aspects of projects. It is also worth mentioning not designated here Infrastructure Architect, people who are engaged in global development and analysis of technical capabilities for the implementation of projects.
')
It turns out that there are 3 types / levels of architects:
In terms of development, we will further consider the tasks and responsibilities of EA and SA, without forgetting, however, the important role of IA.
Briefly, then:
The range of issues and challenges facing EA include:
Questions before Solution Architect are more familiar to simple developers, for example:
The differences can be represented graphically as follows:
EA develops a global work plan for the application, its interaction with other applications. SA is working on specific software. At the same time, EA constantly monitors how the application develops and can make adjustments to the conceptual parts of the application.
For example, at some point there is a need for a new application X, which uses the data generated by application A. In this case, the EA decides to allocate part of application A to a separate service, which will be the data provider for application X. Thus, it can be noticeably reduced work on the implementation of the new application.
From the presented example, it is easy to come to the conclusion that EA should work very well, analyze and monitor how all applications work together, have all the information in a clear and structured way so that you can make the described decisions. The reuse of services and data, to remember or know the specifics of data and services, all this is the responsibility of the EA.
In my opinion, SA should be a practicing programmer, since it is required to know well enough the products and frameworks with which to work, know the limitations and strengths of the technologies that will be used. In turn, EA is also not divorced from the world of technology, since it is necessary to know the conceptual differences in general technologies, to be aware of their development trends. Since the decisions taken in the global software development plan can bury all subsequent projects, or make their development long and difficult if the choice does not match the technological structure of the business.
This diagram shows the dependencies and relationships between different levels of architectural planning. The influence of them on each other. Comment is not worth it, I think.
Possible enterprise architecture artifacts:
The connection between them in the photo below. Sorry for the quality.
About each element from the list you can google separately, but in general it is clear what they mean. It remains to choose the most convenient presentation format.
Some people spoke about how the decision-making process is built in their companies. For example, when approving a plan for a year, it is necessary that architects participate, who are trying to make an analysis of the feasibility of implementation in the required time frame. They determine which projects will require the greatest investment of forces, which can become consumers only and will not require a lot of resources.
No one called specific means for development and control. Anyway, the compilation of tools from Visio, SharePoint, Wiki is used.
For me, questions remain open about how to assess the trend in data growth, data management mechanisms. Best practices on migration of architectures, how the systems work during the modernization. Many, many questions arise of a practical nature, which I will try to find out from the practitioners who I met at the seminar. If there is a result, then I will write more.
From the additional material you can recommend TOGAF9 and the blog Nick Malik .
UPD
The storyteller was Sergei Orlik and it was a compilation of his previous stories about architecture. Slides are available at www.slideshare.net/sorlik/presentations
Most developers, most likely, imagine an architecture only as an application to a specific project, i.e. You can often hear from them "software architecture", but this is only a small part of what is included in the general concept. It is conditionally possible to divide the global concept into several parts, from the general to the particular. You can imagine them in the form of a pyramid:
- Business architecture
- Information Systems Architecture (data streams)
- Technological architecture
Thus, developers most often talk about the technological architecture of the application.
Business architecture, also known as Enterprise, is a presentation of how to effectively reproduce business goals and strategies by creating, improving and combining key requirements, principles and models for successful business development and achieving goals. Definition taken from the English Wikipedia. Enterprise architects should focus on business needs and analyze data flows, i.e. cover the two indicated points. Solution level architects deal with the technological aspects of projects. It is also worth mentioning not designated here Infrastructure Architect, people who are engaged in global development and analysis of technical capabilities for the implementation of projects.
')
It turns out that there are 3 types / levels of architects:
- Enterprise (EA)
- Solution (SA)
- Infrastructure (IA)
In terms of development, we will further consider the tasks and responsibilities of EA and SA, without forgetting, however, the important role of IA.
Differences between Enterprise Architect and Solution Architect
Briefly, then:
- Enterprise - what to do
- Solution - how to do
The range of issues and challenges facing EA include:
- Definition and decision about the equipment on which the application and / or its parts will run.
- Definition of data flows, interaction with other information systems within and outside the company.
- Developing an application deployment plan, determining dependencies.
- Develop an application administration plan and access / security issues.
Questions before Solution Architect are more familiar to simple developers, for example:
- The choice of frameworks for work;
- Views to the user;
- Monitoring the development of the application;
- Solving controversial issues with developers.
The differences can be represented graphically as follows:
EA develops a global work plan for the application, its interaction with other applications. SA is working on specific software. At the same time, EA constantly monitors how the application develops and can make adjustments to the conceptual parts of the application.
For example, at some point there is a need for a new application X, which uses the data generated by application A. In this case, the EA decides to allocate part of application A to a separate service, which will be the data provider for application X. Thus, it can be noticeably reduced work on the implementation of the new application.
From the presented example, it is easy to come to the conclusion that EA should work very well, analyze and monitor how all applications work together, have all the information in a clear and structured way so that you can make the described decisions. The reuse of services and data, to remember or know the specifics of data and services, all this is the responsibility of the EA.
In my opinion, SA should be a practicing programmer, since it is required to know well enough the products and frameworks with which to work, know the limitations and strengths of the technologies that will be used. In turn, EA is also not divorced from the world of technology, since it is necessary to know the conceptual differences in general technologies, to be aware of their development trends. Since the decisions taken in the global software development plan can bury all subsequent projects, or make their development long and difficult if the choice does not match the technological structure of the business.
Responsibility and Impact Levels
This diagram shows the dependencies and relationships between different levels of architectural planning. The influence of them on each other. Comment is not worth it, I think.
Possible enterprise architecture artifacts:
- Project Plans
- Mapping business processes to systems
- Business processes
- Organizational structure
- Technological architecture of systems integration
- Data structures
- Topology deployment systems and their components
- Network topology and equipment connectivity
- Physical placement of systems
- Registers of systems and equipment
- Functional systems
The connection between them in the photo below. Sorry for the quality.
About each element from the list you can google separately, but in general it is clear what they mean. It remains to choose the most convenient presentation format.
The work of architects
Some people spoke about how the decision-making process is built in their companies. For example, when approving a plan for a year, it is necessary that architects participate, who are trying to make an analysis of the feasibility of implementation in the required time frame. They determine which projects will require the greatest investment of forces, which can become consumers only and will not require a lot of resources.
No one called specific means for development and control. Anyway, the compilation of tools from Visio, SharePoint, Wiki is used.
For me, questions remain open about how to assess the trend in data growth, data management mechanisms. Best practices on migration of architectures, how the systems work during the modernization. Many, many questions arise of a practical nature, which I will try to find out from the practitioners who I met at the seminar. If there is a result, then I will write more.
From the additional material you can recommend TOGAF9 and the blog Nick Malik .
UPD
The storyteller was Sergei Orlik and it was a compilation of his previous stories about architecture. Slides are available at www.slideshare.net/sorlik/presentations
Source: https://habr.com/ru/post/146647/
All Articles