Notes of a true architect: just about the most important thing (Part 2)
Architecture is about the future ...
- it was on this thought that we stopped at the end of the 1st part of the article . We continue.
Good architecture is the one that suits its purpose, i.e. allows you to solve its tasks.
Tasks are different. Standard and specific. Local and scale.
But in any case, it is unlikely that anyone would want a house “for one season” (although this is also possible, but this is just from the category of “specific,” and it is unlikely that they will use the services of an architect for such construction) is doubtful so that someone would like to get a system with no prospects for its future development.
')
The mass of useful system characteristics depends on the correctness of the architecture, among which the important one is an indicator of its lifetime in the process of increasing the functionality, growth of data and load.
Good architecture should have the property of sustainability - i.e. a change in the above parameters should not lead to the need for a fundamental review of the implementation of the decision.
This is possible if the design takes into account a set of so-called non-functional requirements. The user starts to notice them only in case of their violation - the user is focused primarily on the functionality that he needs. But this does not mean that this aspect should leave our focus of attention. When these requirements are violated, for the user it often looks simple - the system does not work.
So, non-functional properties include:
In addition, a well-thought-out architecture may allow for the simultaneous development of a system by several performers simultaneously, since the boundaries of responsibility and the points of integration of the components are well defined and clear.
And this has a positive effect on the timing of the project.
Architecture is a way of dealing with complexity.
I do not think that anyone will dispute the fact: IT systems are, in general, systems complex. And the whole practice of creating IT systems and complexes goes under the flag of the struggle with complexity.
Let me remember a long history of wonderful student times.
When it was time to prepare a thesis, I got to a very "correct" teacher, who without fail demanded a chapter from me with the calculation of the reliability of my "hardware-software complex", as my little personal computer application was proudly named. I tried to be indignant, then I was upset - it seemed to me that it was very senseless and wasteful to waste precious time on such a formal question ... But when I came to the library, I learned a lot of interesting things for myself. In particular, I came across the great work of GJ Myers “Software Reliability: Principles and Practices” .
Myers said, for example, that approaches to calculating software reliability are very different from calculations for hardware. And the level of software reliability directly correlates with its complexity. Therefore, key approaches to increase the reliability of software systems boil down to different practices of dealing with complexity.
Unlike hardware, software is too complicated to be “absolutely reliable”. And one of the tenets of the theory of software reliability says: “There is at least one mistake in any program” .
Accordingly, in the software industry there are many practices, approaches, tools that reduce complexity and manage it.
In particular, the creation of high-level languages, specialized (infrastructure) software - DBMS, application servers, etc. All this attempts to break the complex process of implementing software into hierarchical levels, each of which solves the tasks of its level, and each subsequent uses the service of the previous one, “without thinking” exactly how it implements it.
As we clarified above, one of the tasks of the architect is the ability to break the whole system into components, highlighting their areas of responsibility and building a common logic for their interaction.
Thus, when building architecture, we actively use the well-known principle of “divide and conquer”. In our case, you can say this: "Divide into components, modules, layers - and manage each component separately, having built the uniform rules of the game."
In addition to improving reliability, we are touching on another important non-functional property of the system - the ability to modify.
Avoiding monolithic structures, dividing the system into its component parts — modules that function and interact in an understandable way, we increase the ability to make changes to individual components, reducing the impact on other parts to a minimum. Simply put, in the future, in the process of developing the system, this will allow you not to be in a situation “you touch it - it will fall there”.
The architecture should support the future process of managing changes in the system by limiting the influence of the components on each other and providing a means to carry out an assessment of the impact of the upcoming changes.
In addition, in the case of a well-thought-out modular approach to building a system, the possibility arises of parallel and conditionally independent (to a certain extent) implementation of the various components of the system by different performers and even teams and contractors.
Moreover, for the implementation of individual layers it is possible to use various technologies and platforms. It is only necessary to work out their internal integration interaction.
Thus, when we, for example, see several layers on a conceptual architectural scheme, this is not a reason for sadness. This is a reason to rejoice that our system will acquire a remarkable opportunity to evolve for a long time, acquiring functionality and not going beyond its complexity - and therefore, maintaining the quality of reliability and modifiability.
Now from the high level of “Enterprise” we go down “to the ground” - i.e. in projects. And look at the world of the architect through the eyes of participants in software development projects.
What is this mysterious man - an architect?
The code does not write (maybe write, but less often and not now, when we are watching him). He sits himself first in the corner - he thinks, draws, thinks out ... "He soars in the clouds" - the developers think. “Well, well, we'll see,” thinks the boss.
Yes, the code does not write. Often writes on paper. Or on the board. One or with someone - draw, draw ... Discuss. Draw again.
Then he matures ... concept (or vision (vision) - depending on the scale of the task).
The concept implements the main idea, voiced by the “customer of the architecture” (see 1st part of the article ).
As a result, the architect has a set of pictures and a brief presentation explaining the essence of the problem, the task and the approach to its implementation. Next, the process of presenting the architecture to the interested parties and coordination, both from the “business” and from the IT specialists, begins. questions may be different for everyone. And they should be taken into account. The task of this stage is to achieve equal understanding. This is not as easy as it sounds. And this is not always possible ... And ... this is normal. This is part of the profession.
In short, at this stage the art of the architect is to come up with a concept, present it and get approval, after which it can serve as a basis for implementation (this process was discussed in more detail earlier, in the 1st part of the article ).
The architect is not the lucky “coder” and the inventive “kulibin”. This is a person with the responsibility for direction, for the team, for the system ... The success of the work of many people depends on his expertise, thoughtfulness and ability to “look into the future”.
As we said, the design and development of the system should be well preceded by the creation of the target architecture and vision. Those. Before starting a project - you need to clearly define the purpose and see the meaning of future actions.
The architect must believe in this goal. Since he is responsible for ensuring that the “detachment” on the way does not merge in a certain incomprehensible direction - for example, he decided to go to the bathhouse, take a steam bath ... or garden someone to dig ...
When the target vision is chosen, it is clear and consonant to everyone, then it is on its basis that it controls the correctness of the movement.
There is a way “1000 miles”. Step by step - before something working and tangible occurs. And the task of the architect is “not to let him go.” Therefore, in addition to the technical background and the ability to think strategically, he urgently needs true leadership skills and what is now fashionable to call soft skills - that is, ability to negotiate, to work with people, to control oneself well and manage the situation.
It is rare to whom all these various qualities are given from nature. Something is given to us, but something needs to be brought up and grown.
Concept or Vision is only the first step.
Next you need to "go deep into the details" - to work out certain key points of the future system and its components.
And this step involves the development of several models of different levels and purposes - for example, data models, interactions, business processes, state transitions, etc.
To do this, use specialized tools designed for one or another aspect of modeling - the so-called CASE-technology. There are also well-developed standards in this area - ER-models, UML-diagrams, notations for the description of business processes (BPMN, EPC), etc.
The important point here will be the possibility to support a continuous development process - some “working” part of the system should be created from the model - a database structure will be created based on the data model, based on the UML class diagrams - procurement of classes and interfaces for future program code. Also from the side of CASE means it is important to be able to support the reverse process - from the code - to the model.
And yet this is not the code. These are only the first "bridges" - the frame - from concept to the future product.
Graphic notation and models are good. But this is not enough. There must be some description - how to work with it. Yes - without the text - nowhere. This is where the artifact appears as a specification.
Who writes the specifications?
Specifications write system analysts - in terms of functional aspects and system architects - in terms of system (common, key) properties of components and their interaction.
The specification is actually formalized requirements - a detailed statement of the problem for the developer.
What is important for the specification?
First of all, keep a balance between:
One more thing is important.
Strangely enough, the specification should not only limit the developer, but also leave him some freedom - in the area where he makes the decision (and is responsible for it). Of course, he should know about it.
What is it for?
Firstly, it is difficult to foresee and foresee everything in advance. Software development is a rather complicated area, with infinite variability of possible work scenarios.
Secondly, if this is not done, it will deprive the “system” and the team that develops it, the space for self-development.
Excessive “organization” deprives of creativity. The person begins to feel like a "cog". And this is terribly demotivating. In my memory there were several cases in which developers lost interest and left for just this reason. Strangely enough, when creating a system architecture, it is necessary to provide “islands of chaos” - “islands of freedom” for the creativity of other people.
Awareness of the need to build an enterprise architecture and the implementation of its development practices indicates a sufficient level of maturity of the company.
There are many companies where there is no understanding of the need for planning an IT architecture even for the near future - at least in the horizon of 1 year. Nevertheless, they are somehow developing - business is changing, new requirements are emerging, IT systems are being modernized, new integration flows are emerging, as well as channels for disseminating information in the enterprise, etc.
What happens if you do not think about the architecture of the enterprise?
The answer is simple - either some opportunities will be missed (lost profits), or some losses (additional costs) will happen.
Because if we don’t look into the “picture of the future”, we don’t try to see it today - it will overtake us “suddenly”, but it will still overtake. What will happen? Maybe nothing terrible will happen. Or maybe the company will lose a little from its competitiveness, and maybe something more serious will happen that will jeopardize its core business. We do not know this in advance.
But hope and "roulette" is a very unreliable development strategy, both for business and for IT that provides business.
The element of chance and chaos will certainly be present in any case. We cannot predict everything. There are too many external factors affecting the situation.
But the question is - do we want to make it manageable? Do we want to expand our zone of influence, or rely "on chance"?
If we want, then this is already the next level of maturity - when there is an awareness of the need to build and manage enterprise architecture. In this case, the company "tells" itself that we are ready to "look into the future" and form a certain picture - 1-3-5 years ahead. Of course, it will be corrected "in the course of the play." But we must realize which directions are valuable for us, what we are ready to invest in and why? Where are we willing to take the risk? Where could be our “wow”? Where do we need, above all, stability, and where can we be a bit “crazy”? What we want to be more talented than other companies, what are our real chances? And where do we just need proven replicable solutions?
One awareness is not enough. It is not so easy to “see” the architecture, to build architectural processes (including changes and controls). This is not an “elementary” (routine) action. And it is possible that with the wrong decisions and incorrect approaches, we can do more harm than good - and the company in the pursuit of a beautiful, but not realistic picture can incur unnecessary costs.
Here, to some extent, the previously mentioned architectural frameworks can come to the rescue, which include both the standards for describing the architecture and the methodology of its development. Reliance on them does not exclude, but reduces the risk of failure in this difficult task.
The value of applying any standard, any reference practice is the ability to adapt. Any company is unique. There are no two identical banks, retail companies, factories, city administrations, etc. Everywhere has its own specifics - geographical, human, organizational, technological, etc. Therefore, an attempt to “remove tracing paper” from one organization — and apply this practice to another, without any changes — most likely will not lead to anything good. You can learn from some experience. But he must be adapted to his company.
Building a corporate architecture is a creative process, unique - how unique each company and the people who work in it are.
In addition, the architectural processes of the company affect the architectural processes - especially the decision-making model, methods of communication, informational openness, etc.
Architecture is about the future, about people, about the sustainable development of the company.
So, if a company wants to grow steadily, then it needs to start investing in the architecture and processes of managing its change.
- it was on this thought that we stopped at the end of the 1st part of the article . We continue.
What is good architecture?
Good architecture is the one that suits its purpose, i.e. allows you to solve its tasks.
Tasks are different. Standard and specific. Local and scale.
But in any case, it is unlikely that anyone would want a house “for one season” (although this is also possible, but this is just from the category of “specific,” and it is unlikely that they will use the services of an architect for such construction) is doubtful so that someone would like to get a system with no prospects for its future development.
')
The mass of useful system characteristics depends on the correctness of the architecture, among which the important one is an indicator of its lifetime in the process of increasing the functionality, growth of data and load.
Good architecture should have the property of sustainability - i.e. a change in the above parameters should not lead to the need for a fundamental review of the implementation of the decision.
This is possible if the design takes into account a set of so-called non-functional requirements. The user starts to notice them only in case of their violation - the user is focused primarily on the functionality that he needs. But this does not mean that this aspect should leave our focus of attention. When these requirements are violated, for the user it often looks simple - the system does not work.
So, non-functional properties include:
- Reliability;
- Performance;
- Modifiability;
- Scalability;
- Ability to integrate;
- Security.
In addition, a well-thought-out architecture may allow for the simultaneous development of a system by several performers simultaneously, since the boundaries of responsibility and the points of integration of the components are well defined and clear.
And this has a positive effect on the timing of the project.
Architecture is a way of dealing with complexity.
I do not think that anyone will dispute the fact: IT systems are, in general, systems complex. And the whole practice of creating IT systems and complexes goes under the flag of the struggle with complexity.
Let me remember a long history of wonderful student times.
When it was time to prepare a thesis, I got to a very "correct" teacher, who without fail demanded a chapter from me with the calculation of the reliability of my "hardware-software complex", as my little personal computer application was proudly named. I tried to be indignant, then I was upset - it seemed to me that it was very senseless and wasteful to waste precious time on such a formal question ... But when I came to the library, I learned a lot of interesting things for myself. In particular, I came across the great work of GJ Myers “Software Reliability: Principles and Practices” .
Myers said, for example, that approaches to calculating software reliability are very different from calculations for hardware. And the level of software reliability directly correlates with its complexity. Therefore, key approaches to increase the reliability of software systems boil down to different practices of dealing with complexity.
Unlike hardware, software is too complicated to be “absolutely reliable”. And one of the tenets of the theory of software reliability says: “There is at least one mistake in any program” .
Accordingly, in the software industry there are many practices, approaches, tools that reduce complexity and manage it.
In particular, the creation of high-level languages, specialized (infrastructure) software - DBMS, application servers, etc. All this attempts to break the complex process of implementing software into hierarchical levels, each of which solves the tasks of its level, and each subsequent uses the service of the previous one, “without thinking” exactly how it implements it.
As we clarified above, one of the tasks of the architect is the ability to break the whole system into components, highlighting their areas of responsibility and building a common logic for their interaction.
Thus, when building architecture, we actively use the well-known principle of “divide and conquer”. In our case, you can say this: "Divide into components, modules, layers - and manage each component separately, having built the uniform rules of the game."
In addition to improving reliability, we are touching on another important non-functional property of the system - the ability to modify.
Avoiding monolithic structures, dividing the system into its component parts — modules that function and interact in an understandable way, we increase the ability to make changes to individual components, reducing the impact on other parts to a minimum. Simply put, in the future, in the process of developing the system, this will allow you not to be in a situation “you touch it - it will fall there”.
The architecture should support the future process of managing changes in the system by limiting the influence of the components on each other and providing a means to carry out an assessment of the impact of the upcoming changes.
In addition, in the case of a well-thought-out modular approach to building a system, the possibility arises of parallel and conditionally independent (to a certain extent) implementation of the various components of the system by different performers and even teams and contractors.
Moreover, for the implementation of individual layers it is possible to use various technologies and platforms. It is only necessary to work out their internal integration interaction.
Thus, when we, for example, see several layers on a conceptual architectural scheme, this is not a reason for sadness. This is a reason to rejoice that our system will acquire a remarkable opportunity to evolve for a long time, acquiring functionality and not going beyond its complexity - and therefore, maintaining the quality of reliability and modifiability.
Why do we need architects? What is their role? What can we expect from them and why?
Now from the high level of “Enterprise” we go down “to the ground” - i.e. in projects. And look at the world of the architect through the eyes of participants in software development projects.
What is this mysterious man - an architect?
The code does not write (maybe write, but less often and not now, when we are watching him). He sits himself first in the corner - he thinks, draws, thinks out ... "He soars in the clouds" - the developers think. “Well, well, we'll see,” thinks the boss.
Yes, the code does not write. Often writes on paper. Or on the board. One or with someone - draw, draw ... Discuss. Draw again.
Then he matures ... concept (or vision (vision) - depending on the scale of the task).
The concept implements the main idea, voiced by the “customer of the architecture” (see 1st part of the article ).
Presentation of the concept (vision)
As a result, the architect has a set of pictures and a brief presentation explaining the essence of the problem, the task and the approach to its implementation. Next, the process of presenting the architecture to the interested parties and coordination, both from the “business” and from the IT specialists, begins. questions may be different for everyone. And they should be taken into account. The task of this stage is to achieve equal understanding. This is not as easy as it sounds. And this is not always possible ... And ... this is normal. This is part of the profession.
In short, at this stage the art of the architect is to come up with a concept, present it and get approval, after which it can serve as a basis for implementation (this process was discussed in more detail earlier, in the 1st part of the article ).
The architect is not the lucky “coder” and the inventive “kulibin”. This is a person with the responsibility for direction, for the team, for the system ... The success of the work of many people depends on his expertise, thoughtfulness and ability to “look into the future”.
As we said, the design and development of the system should be well preceded by the creation of the target architecture and vision. Those. Before starting a project - you need to clearly define the purpose and see the meaning of future actions.
The architect must believe in this goal. Since he is responsible for ensuring that the “detachment” on the way does not merge in a certain incomprehensible direction - for example, he decided to go to the bathhouse, take a steam bath ... or garden someone to dig ...
When the target vision is chosen, it is clear and consonant to everyone, then it is on its basis that it controls the correctness of the movement.
There is a way “1000 miles”. Step by step - before something working and tangible occurs. And the task of the architect is “not to let him go.” Therefore, in addition to the technical background and the ability to think strategically, he urgently needs true leadership skills and what is now fashionable to call soft skills - that is, ability to negotiate, to work with people, to control oneself well and manage the situation.
It is rare to whom all these various qualities are given from nature. Something is given to us, but something needs to be brought up and grown.
Who are you - the perfect specification?
Concept or Vision is only the first step.
Next you need to "go deep into the details" - to work out certain key points of the future system and its components.
And this step involves the development of several models of different levels and purposes - for example, data models, interactions, business processes, state transitions, etc.
To do this, use specialized tools designed for one or another aspect of modeling - the so-called CASE-technology. There are also well-developed standards in this area - ER-models, UML-diagrams, notations for the description of business processes (BPMN, EPC), etc.
The important point here will be the possibility to support a continuous development process - some “working” part of the system should be created from the model - a database structure will be created based on the data model, based on the UML class diagrams - procurement of classes and interfaces for future program code. Also from the side of CASE means it is important to be able to support the reverse process - from the code - to the model.
And yet this is not the code. These are only the first "bridges" - the frame - from concept to the future product.
Graphic notation and models are good. But this is not enough. There must be some description - how to work with it. Yes - without the text - nowhere. This is where the artifact appears as a specification.
Who writes the specifications?
Specifications write system analysts - in terms of functional aspects and system architects - in terms of system (common, key) properties of components and their interaction.
The specification is actually formalized requirements - a detailed statement of the problem for the developer.
What is important for the specification?
First of all, keep a balance between:
- accuracy, clarity / and too high detail;
- universality / and simplicity;
- full coverage / and realistic resources.
One more thing is important.
Strangely enough, the specification should not only limit the developer, but also leave him some freedom - in the area where he makes the decision (and is responsible for it). Of course, he should know about it.
What is it for?
Firstly, it is difficult to foresee and foresee everything in advance. Software development is a rather complicated area, with infinite variability of possible work scenarios.
Secondly, if this is not done, it will deprive the “system” and the team that develops it, the space for self-development.
Excessive “organization” deprives of creativity. The person begins to feel like a "cog". And this is terribly demotivating. In my memory there were several cases in which developers lost interest and left for just this reason. Strangely enough, when creating a system architecture, it is necessary to provide “islands of chaos” - “islands of freedom” for the creativity of other people.
When do companies need to invest in Architecture? And what will happen if this is not done?
Awareness of the need to build an enterprise architecture and the implementation of its development practices indicates a sufficient level of maturity of the company.
There are many companies where there is no understanding of the need for planning an IT architecture even for the near future - at least in the horizon of 1 year. Nevertheless, they are somehow developing - business is changing, new requirements are emerging, IT systems are being modernized, new integration flows are emerging, as well as channels for disseminating information in the enterprise, etc.
What happens if you do not think about the architecture of the enterprise?
The answer is simple - either some opportunities will be missed (lost profits), or some losses (additional costs) will happen.
Because if we don’t look into the “picture of the future”, we don’t try to see it today - it will overtake us “suddenly”, but it will still overtake. What will happen? Maybe nothing terrible will happen. Or maybe the company will lose a little from its competitiveness, and maybe something more serious will happen that will jeopardize its core business. We do not know this in advance.
But hope and "roulette" is a very unreliable development strategy, both for business and for IT that provides business.
The element of chance and chaos will certainly be present in any case. We cannot predict everything. There are too many external factors affecting the situation.
But the question is - do we want to make it manageable? Do we want to expand our zone of influence, or rely "on chance"?
If we want, then this is already the next level of maturity - when there is an awareness of the need to build and manage enterprise architecture. In this case, the company "tells" itself that we are ready to "look into the future" and form a certain picture - 1-3-5 years ahead. Of course, it will be corrected "in the course of the play." But we must realize which directions are valuable for us, what we are ready to invest in and why? Where are we willing to take the risk? Where could be our “wow”? Where do we need, above all, stability, and where can we be a bit “crazy”? What we want to be more talented than other companies, what are our real chances? And where do we just need proven replicable solutions?
One awareness is not enough. It is not so easy to “see” the architecture, to build architectural processes (including changes and controls). This is not an “elementary” (routine) action. And it is possible that with the wrong decisions and incorrect approaches, we can do more harm than good - and the company in the pursuit of a beautiful, but not realistic picture can incur unnecessary costs.
Here, to some extent, the previously mentioned architectural frameworks can come to the rescue, which include both the standards for describing the architecture and the methodology of its development. Reliance on them does not exclude, but reduces the risk of failure in this difficult task.
The value of applying any standard, any reference practice is the ability to adapt. Any company is unique. There are no two identical banks, retail companies, factories, city administrations, etc. Everywhere has its own specifics - geographical, human, organizational, technological, etc. Therefore, an attempt to “remove tracing paper” from one organization — and apply this practice to another, without any changes — most likely will not lead to anything good. You can learn from some experience. But he must be adapted to his company.
Building a corporate architecture is a creative process, unique - how unique each company and the people who work in it are.
In addition, the architectural processes of the company affect the architectural processes - especially the decision-making model, methods of communication, informational openness, etc.
Architecture is about the future, about people, about the sustainable development of the company.
So, if a company wants to grow steadily, then it needs to start investing in the architecture and processes of managing its change.
Source: https://habr.com/ru/post/276613/
All Articles