Notes of a true architect: just about the most important thing (Part 1)
All of the following is solely a private opinion of the author, not related to any employer or vendor.
“Hmm ... a true architect ... And what are these? - you ask and think. - Lies, come on! Now we will tell another concept of "blah blah blah.2.0". We know, we swam, we saw the architects "hovering in the sky" and their speculative constructions. "
And you will be right: a normal "patsansky" architect is a very busy person, and, as a rule, he has no time to write articles ... But! It happens that the moment comes - and the person’s desire to share his experience, tell the world about his successes and difficulties is so high that time is there, and the fear of public statements inherent in our techie brother retreats. In addition, colleagues in the shop have long urged me to start such activities.
I decided to start with a somewhat general topic - IT architecture as a whole. Why not immediately go directly to the details that most occupy readers of technical blogs?
The answer is simple: it really hurts a lot of questions, interpretations and misinterpretations arise around the work and tasks of architects. And to move on, you need to build a kind of “common coordinate system” - a certain starting point.
During my work there was a certain “vision” of what is happening, which I would like to share and discuss with my colleagues.
')
So, let's try to find answers to the following questions.
If you have ever asked such questions, and they are of interest to you, then this article is for you - I invite you to reflect on it together.
So, let's start “from the stove” - let's try to define this concept.
Not only architects, but also ancient philosophers paid attention to terminology in their conversations with the honorable rulers of states:
"If the name is wrong (does not correspond to the essence), then the word is contrary to the deed, and when the word is contrary to the deed, then the deed will not be executed, and if the deed is not performed, then the ceremonies and music will not flourish, and if the ceremonies and music will not flourish , then the punishments will not be correct, and when the punishments are perverted, the people will not know how to behave. Therefore, for a noble husband it is necessary that he certainly [could name the correct names of things so that] what he said was fulfilled and that there was nothing dishonorable (dishonest) in his words ”
/ Confucius "Judgments and conversations" /
Nevertheless, I will not give all possible definitions of the term “architecture” that are remarkable in their completeness, originality and deep meanings. And there is no such task - to give an ideal definition (if at all possible). The main thing is to understand the essence of the subject.
You know ... I won’t give a definition at all. At least right now. I'll do it later.
Even in such a strict science as mathematics, as my teacher from the university used to say, the age of ideal definitions has long passed:
“You do not remember the definition from the textbook - and it is not necessary. Try to go from examples - and thus build a concept. "
So, Architecture ... Yes, it is these images that are often placed on the title page of the architectural IT concept and become a symbol ("logo") of the architectural divisions of large companies.
Of course, the first thing that comes to mind is the connection to the well-known area of construction. The architecture of buildings, structures, cities is a sphere well known and having a long history.
Is the analogy fair?
Of course! More than!
Whole studies on this topic are known - for example, Pat Helland's article “Metropolis” .
The architecture of buildings, structures, urban landscapes has evolved so long ago and has become so familiar to human perception that this term does not require an explanation even to people very far from the construction industry ...
What associations do we have with the word “architecture” in its classical meaning?
There are two main aspects, the direction in which the architecture is being worked out:
It is also worth adding the 3rd - standardization and quality. Unfortunately, even in the classical architectural business, in the field of construction, they sometimes forget about this moment. The consequences are known to all, and they are very sad (in some cases even tragic) ...
Absolutely appropriate is the analogy: in order for the construction of IT systems and complexes to be completed successfully - we, like in construction, need to think and solve this set of architectural issues - before rushing to “code” or “figure”.
And it is necessary to make a start at the same time ... That's right - from the destination.
The first questions we ask ourselves are:
As you can see, this is a very diverse list of issues. And all of them are to some extent related to the IT architecture of the enterprise. Not all of them are “in power”, in the zone of direct responsibility of the architect, but they are in the zone of his influence. And the next section is about that. What is worth thinking about before ...
There is such a theme known in all large companies - “target architecture”, mythical and mysterious, almost like love: “Everyone talks about her, but few have seen it” / La Rochefouco /
Therefore, the target architecture must answer, first of all, the question - why are we doing this? Those. it indicates the purpose, the meaning of our activity. And only then we think and decide - how we will achieve this, at the expense of which technologies, on which platforms.
Before rushing to answer the question "how" (to do, implement the system, platform, etc.), make sure that you answered the question "why."
It's simple! And if this simple (and seemingly obvious, isn't it?) Step is not done, but rush to build schemes and code, code, code ... then there is a big chance that this work will fly away to the basket! And as a result, you and your team, and your customers will experience great sadness. Ask yourself this question not at the end, but at the beginning of your “race”.
How to ask such questions? When and under what circumstances?
We formulate more strictly: in the framework of what processes, who and when raises such questions, as well as who is obliged to find answers to them that are understandable to all participants.
There is clearly at least one conclusion: these questions need to be puzzled to the starting point of the project. And even until its initiation. “But how is that?” - the question may arise: “We have long been accustomed to, that all IT activities are carried out in the framework of projects, and in the case of flexible methods - in the framework of sprints”.
This is where the interesting begins ... Let's hear what the “leading dog breeders” of the IT industry say on this topic - that is, organizations creating and disseminating various standards and reference practices.
So, OpenGroup recently released the concept of IT4IT . The IT operating model presented there includes a set of four basic “value chains” (VAD). One of them is “Strategy to portfolio”, within which a “portfolio of projects” is being formed, starting from what we want to see (target vision) and from the as-is situation (current architecture). Thus, a bridge to our desired “picture of the future” is built through the IT strategy and project portfolio.
/ It's time to ask yourself about how is it customary in our company to form a “project portfolio”? How are projects generated? At what stage are architects involved in this process? Who makes the decision to launch a project? /
Thus, the right way looks like this:
First, the target architecture ... More precisely, first the business strategy, then the target architecture that supports it, then the IT strategy, which reflects the transition from the current state to the target one, and finally, in accordance with the IT strategy, the formation of a portfolio of projects.
That is why the architects at the enterprise so persistently speak about the target, about the need to match the projects to its channel, about the need to fix deviations (temporary and workaround solutions), etc. This is their direct responsibility. This is their job. And it is their responsibility. And for them it is important that conversations about architecture are not infinite in nature, but ended with quite definite delivery - and certain (fixed decisions).
Does this happen often?
No, of course ... Mr. Chaos interferes in our harmonious system. More precisely, the people who create it themselves, consciously or unconsciously. However, it is not necessary to choose - and we also need to somehow exist in the circumstances offered by life - uncertainty, inconsistency, confusion, etc.
Let's try to figure out how everything happens, and what can be done about it.
We can talk endlessly about the target architecture (as well as about love) ... And therefore, it is important to fix a certain vision - to get a “picture of the future”. Or several options - several “pictures”.
Why is it important to fix? It would seem an obvious question, but oddly enough, a lot of spears break around it.
Because - the target architecture is our "support from the future." Imagine - what chaos will arise in our portfolio of projects, if it changes all the time?
Who is engaged in a similar study and is responsible for the quality of the result? Of course, an IT architect is his area of creativity, influence and responsibility. At the same time, he communicates with a large number of people, collects and processes a lot of information, studies existing analogues, tries something. Finally, it offers a kind of holistic solution - an architectural concept. It is presented for further discussion and approval as a target architecture - first in a very general sense - as a concept or vision.
When the target vision has appeared, you need to try to make sure that all powerful people (they are called “stakeholders”) see in it some value for themselves and come to an agreement on it. Thus, the criterion for stopping this “fascinating lesson” in discussing architectural concepts will be a reduction of comments from decision makers to a certain minimum.
As well as in any dispute, in the process of architectural debates people often overwhelm emotions. What is important to us? It is important on the one hand, not to miss any valuable comments, opportunities or needs. On the other hand, to direct the process in a constructive direction. Those. It is necessary to translate all judgments into specifics. In other words, to demand justification - both from the speaker, who presented the option of architecture for consideration, and from the questioner. The level of "like - do not like" - not the best way to build a similar process, because he is weakly productive.
A good way is an approach in which some proposed solution is “tested for sustainability” - questions from the “what if ...” series. A look at 360 around this topic.
To streamline the activities of making such collective decisions in large companies use the practice of "architectural committees". People who are affected by this will be involved in them - from business to those responsible for IT infrastructure and system maintenance. And the concepts are approved there. Not always this process in practice looks optimal and effective. But other options have not yet come up.
You can go into the constructive, if
A lot also depends on the leading architectural meetings - how strong is his position as a leader in this team, how respected is this person, how he is able to build a collective polemic in the framework of the constructive.
There are examples of the best organizational practices - on how to build architectural processes, when and what to bring to collegiate discussions on committees, how to submit and process comments, etc. And there are companies where such processes are brought to life. But even the best reference practices will not work if people do not have the initial mood to agree, and the company does not maintain an atmosphere of mutual respect and trust for each other.
Here the question may arise: what to do if really such a mood is not currently traced? Can I change it?
Firstly, it is necessary to see and realize the problem, suspend the discussion directly on the topic of the meeting, since when people get into emotions the level of argumentation, logical arguments stop working.
The second step is to try to see the positive intention of a person who objects, as it may seem to us, very strange - for example, he transfers the focus of attention to another subject for him, leads him to the side, etc. And to see your own commitment, if this in turn begins to annoy you. If we “caught the moment” in time, and the passions have not yet reached a high level, we managed to “press a pause”, realize it and mentally formulate it, then it will be harder for us to “vytsepit for emotion” - this is already good.
The third step is to “return” his intention to the person, but in a positive formulation. Thus, he was not just told that “I can hear you,” but he was really heard and given feedback. It would be nice to write it down and promise to return to this important and pressing issue later. And ask permission to continue the meeting.
The severity subsides, the constructive attitude remains.
Of course, it is not so simple. Easy to write - hard to do. We need experience and training in communications and negotiations. This topic is very extensive, and it will not work out to reveal it here, just to slightly outline and create confidence that such approaches are there, they are workers, and if you like, you can find them, study them and work through them in practice (better with the help of an experienced mentor).
In short, we come to the conclusion that architectural practice is in fact a part of corporate culture, a model of decision making, a common style of organization and interaction of employees within it.
In other words, the level of management of IT architecture and strategy is one of the components of the level of maturity of the company as a whole, which shows its ability to sustainability and development.
I note that the "maturity" in relation to the company is not determined by its size or its age. There are quite large companies that do not have a high level of maturity: i.e. They do not seek to “understand themselves” - their business, their employees, their goals. And strategic initiatives are often formal.
While there are startups in which people quickly come to the conclusion that, for example, one class coding (if we talk about the IT sector) is not enough - some organizing and directing force is needed.
And there are real examples of this. Recently, my architect friend was invited to participate in a similar project, in which good developers are already working, working with drive and interest, on new technologies, etc.And at the same time they say: “it somehow strangely comes out - code-code, but somehow ... it is not clear what result we are moving towards.”
In other words, a company can at an early stage come to a fairly high level of maturity, which increases its chances of being successful. And, moreover, and perhaps even more important - it increases the level of pleasure to work in such a company.
Now they write a lot about the fact that banks are facing competition with IT companies. And the leaders of banks are beginning to quickly reorganize management practices for IT - introduce flexible methods, buy IT start-ups, etc. But it does not make them IT companies. Why?Because people who work in google or amazon will not work in banks. This is not "their format." And it's not about the formal methods of managing the development and management of projects. Compare approaches to working conditions, relationships in these companies, ways of doing business, etc. What is the difference?These are companies of different cultures, different “ways of life”. A bank is not an IT company, and never will be. (As well as the IT company will never be a bank). So why should banks ... not remain banks, exploring and developing their strengths? (And they, undoubtedly, have them, including in IT.) Instead of rushing from the extreme - to the extreme: we transfer IT to outsourcing as a non-core supporting activity, then we are preparing for competition with IT companies.
And this is directly related to the issue of maturity.
A mature company, no matter what size, age, capital level, geography it is, whatever industry it belongs to - knows “itself”, sees “its future”, understands its business, hears its employees. And he seeks to find and build his own path of development, rather than blindly copying and trying on someone else's self ...
Remembering the tale of "Cinderella" - no matter how much you want to marry a prince, you should not try to cut off your heel, trying to fit into someone else's crystal shoe.
Each company has its own talent, its own theme. A conscious approach to the development of architecture takes into account the specifics of the company, tasks, project, their uniqueness.
Now it's time to turn to standards. And following the precepts of the wise Confucius, to give clear definitions of the concepts of interest to us, so that the “ceremony and music” flourish, and the “said” will be fulfilled.
As part of the IT architecture, there are several detailed standards.
First of all, it is ISO / IEC 42010: 2007 , where you can find the following definition:
The framework defines the methodology for solving a particular class of problem. From the word "method" - a repeatable approach, the use of which leads to predictable results.
What are their value frameworks? In that once found, perhaps by chance, a successful solution is realized and applied further in such situations. At the same time, the framework does not dictate the solution thoroughly and completely, leaving the so-called "extension points".
There are two complementary and multidirectional processes in the framework:
Thus, following the frameworks, enriching them with our own identifiable patterns, we get an excellent ability to manage development.
The ability to develop is a very important quality for a company, especially in times of crisis, because allows companies to remain competitive in the face of uncertainty and variability.
It is no coincidence that the requirement of "adaptability" is increasingly heard in relation to IT organizations. Sometimes this leads to unreasonably high expectations - to be able to solve completely different tasks “from one box”. This is not always justified. There is a more efficient way - to use the component architecture, without overloading tools and technologies with unusual and redundant functionality for them. This option is much more transparent and stable in use. But it also requires costs - it is not enough just a narrow knowledge of a certain one system - you need to combine many systems, integrate into a single IT landscape.
And the role of the IT architect, his task - just to help in this process. He does not make decisions alone, he collects and presents information in such a way that it is understandable to many people in the company - from business to engineers - i.e. prepares the ground for a collective decision. This does not mean that he should not have technological knowledge - just the opposite - the practice of working with technologies is one of the key aspects of his work. But as will be shown later, it is far from the only one.
So, the key meaning of architecture and the key tasks of architects is to determine the composition of components, their responsibility and interrelation, starting from a specific applied task that we solve.
In my opinion, this is a completely worthy mission, requiring various foci of attention and diverse competences - both technological and systemic, as well as communicative and organizational.
Finishing the topic with the definitions, I will give one more thing from Oracle , which, it seemed to me, very well reflects the essence and depth of the subject:
Like any artist who solves a problem posed by someone, the architect has ... right - the one who put it - that is, Customer! Who can be such a customer and how the “process of ordering the architecture” may look like depends on the IT organization's approach to organizing IT processes and can be a topic for a separate discussion.
Anyway, the Customer has, first of all, a certain need which he needs to "close". And he may also have his own ideas and his own “vision” on this score, which he, too, may be interested to realize.
For example, working in one bank, I received such an order - “... and also I would like the vault architecture to be such that the vault performs both operational and analytical functions ... in short, you need real time storage!”
It puzzled me a little, because This is a rather atypical and difficult requirement for systems of this class, but as they say, the task has been set - it must be done. As a result, a concept emerged that was slightly different from the original one — not “real time”, but “just-in-time” (the idea was borrowed from the famous principle of organizing production at Toyota - “just in time”). Thus, the initial requirement was somewhat relaxed and more realistic in terms of technical implementation, while the Customer was satisfied with the way his initial “vision” was taken into account.
Thus, no matter how formal and strict our field of activity may look, we need to know and even “feel” the Customer, his wishes and needs, his fears and even some negative experience. And we need to be able to present the concept of the solution in such a way that he wants to “buy” this product - i.e. so that the presented “picture of the future” eventually (perhaps after a series of discussions and discussions) coincided with his expectations - and he wanted to move, to invest in this direction.
It is necessary to note one more, in my opinion, an important detail. In addition to the requirements expressed by the Customer in an explicit form, there is always a set of “default” requirements - those that are implied, but not explicitly stated.
A professional always keeps an eye on his entire field, he controls the situation, he knows more and deeper about it than his client. Otherwise, the client would not have addressed him. And he must always remember that he is a professional, and he has a responsibility.
Thus, the recently released “Everest” film very concretely shows the tragic consequences of the situation where the pros blindly follow the client’s “wishes”.
Here another “hackneyed” term pops up - customer orientation.
Yes, of course, to know, to understand, to respect the internal client is necessary. But the performer is always responsible for the result. And more professionally - to refuse the client something, even to go into conflict, rather than let events happen, the consequences of which can be fatal.
And again we turn to the field of construction and repair, all familiar and intuitive. Any self-respecting specialist - plumber or electrician - will not be under any pressure from the client to implement the project with violations of technical standards. And lead a clear argument.
So why should IT be any different? Perhaps the consequences will not be so dramatic. But if we can say with enough confidence about the risks, we need to say about them. It will be honest and respectful towards your customer.
The customer can afford to live for today, all sorts of “quicwins”, to get involved in one super-innovation, then another, to be captured by trends and fashion trends that technical marketers so skillfully represent at various conferences and events from IT vendors.
An architect, while remaining a professional with a “cold nose,” should be able to look at 3, 5, 10 steps ahead. And what's more - to be able to switch the view of your client to the future. Trying to come to a common understanding, to a joint picture of reality, to which I would like to come in the foreseeable period, which I would like to follow and invest efforts for its realization.
Architecture is about the future ...
It is in this context that later in the 2nd part of the article I will put the strange question: “What is good architecture?” However, it does not look so strange considering all the above. Since He focuses on some “boring” things, which, however, will save our system, our client, from unwanted scenarios for further development.
“Hmm ... a true architect ... And what are these? - you ask and think. - Lies, come on! Now we will tell another concept of "blah blah blah.2.0". We know, we swam, we saw the architects "hovering in the sky" and their speculative constructions. "
And you will be right: a normal "patsansky" architect is a very busy person, and, as a rule, he has no time to write articles ... But! It happens that the moment comes - and the person’s desire to share his experience, tell the world about his successes and difficulties is so high that time is there, and the fear of public statements inherent in our techie brother retreats. In addition, colleagues in the shop have long urged me to start such activities.
I decided to start with a somewhat general topic - IT architecture as a whole. Why not immediately go directly to the details that most occupy readers of technical blogs?
The answer is simple: it really hurts a lot of questions, interpretations and misinterpretations arise around the work and tasks of architects. And to move on, you need to build a kind of “common coordinate system” - a certain starting point.
During my work there was a certain “vision” of what is happening, which I would like to share and discuss with my colleagues.
')
So, let's try to find answers to the following questions.
- What is architecture?
- What is the target architecture?
- What are architectural standards and frameworks and why are they needed?
- Who orders the architecture, what wishes and needs expressed and unspoken can be from our customer?
- What kind of architecture can be called good architecture?
- Why do we need architects? What is their role? What to expect from them and why?
- When do companies need to invest in architecture? What happens if you do not?
If you have ever asked such questions, and they are of interest to you, then this article is for you - I invite you to reflect on it together.
What is architecture?
So, let's start “from the stove” - let's try to define this concept.
Not only architects, but also ancient philosophers paid attention to terminology in their conversations with the honorable rulers of states:
"If the name is wrong (does not correspond to the essence), then the word is contrary to the deed, and when the word is contrary to the deed, then the deed will not be executed, and if the deed is not performed, then the ceremonies and music will not flourish, and if the ceremonies and music will not flourish , then the punishments will not be correct, and when the punishments are perverted, the people will not know how to behave. Therefore, for a noble husband it is necessary that he certainly [could name the correct names of things so that] what he said was fulfilled and that there was nothing dishonorable (dishonest) in his words ”
/ Confucius "Judgments and conversations" /
Nevertheless, I will not give all possible definitions of the term “architecture” that are remarkable in their completeness, originality and deep meanings. And there is no such task - to give an ideal definition (if at all possible). The main thing is to understand the essence of the subject.
You know ... I won’t give a definition at all. At least right now. I'll do it later.
Even in such a strict science as mathematics, as my teacher from the university used to say, the age of ideal definitions has long passed:
“You do not remember the definition from the textbook - and it is not necessary. Try to go from examples - and thus build a concept. "
So, Architecture ... Yes, it is these images that are often placed on the title page of the architectural IT concept and become a symbol ("logo") of the architectural divisions of large companies.
Of course, the first thing that comes to mind is the connection to the well-known area of construction. The architecture of buildings, structures, cities is a sphere well known and having a long history.
Is the analogy fair?
Of course! More than!
Whole studies on this topic are known - for example, Pat Helland's article “Metropolis” .
The architecture of buildings, structures, urban landscapes has evolved so long ago and has become so familiar to human perception that this term does not require an explanation even to people very far from the construction industry ...
What associations do we have with the word “architecture” in its classical meaning?
- beauty, the image of the era, aesthetic perception;
- convenience and comfort of use, compliance with the intended purpose;
- manufacturability, accuracy of design drawings;
- infrastructure / engineering components (communications, water and power supply system);
- safety, stability, reliability;
- following industry quality standards
There are two main aspects, the direction in which the architecture is being worked out:
- human perception;
- technological aspect.
It is also worth adding the 3rd - standardization and quality. Unfortunately, even in the classical architectural business, in the field of construction, they sometimes forget about this moment. The consequences are known to all, and they are very sad (in some cases even tragic) ...
Absolutely appropriate is the analogy: in order for the construction of IT systems and complexes to be completed successfully - we, like in construction, need to think and solve this set of architectural issues - before rushing to “code” or “figure”.
And it is necessary to make a start at the same time ... That's right - from the destination.
The first questions we ask ourselves are:
- Why do we do this?
- What problems and tasks are there now? Who does this affect? What does this mean? What will happen if they are not solved?
- What can our “picture of the future” look like when we do this?
- How will this affect people who are currently working and will work with this functionality?
- How will this affect other systems? How will the information flow within the company?
- To whom, how and when should the information generated be available? How will it relate to other information generated by the company?
- What set of steps (projects) should we do - to arrive at the desired result?
- How much is it? What are the alternatives?
- Have we ever done something like this before? What do we want to take from this experience? What do we want to try to do differently? Why?
- Maybe someone already did it? How did they do it? What results did you get? What problems have you encountered?
- We go to it, because it will give us ...
As you can see, this is a very diverse list of issues. And all of them are to some extent related to the IT architecture of the enterprise. Not all of them are “in power”, in the zone of direct responsibility of the architect, but they are in the zone of his influence. And the next section is about that. What is worth thinking about before ...
“I see a goal - I see no obstacles” or What is a target architecture?
There is such a theme known in all large companies - “target architecture”, mythical and mysterious, almost like love: “Everyone talks about her, but few have seen it” / La Rochefouco /
Therefore, the target architecture must answer, first of all, the question - why are we doing this? Those. it indicates the purpose, the meaning of our activity. And only then we think and decide - how we will achieve this, at the expense of which technologies, on which platforms.
Before rushing to answer the question "how" (to do, implement the system, platform, etc.), make sure that you answered the question "why."
It's simple! And if this simple (and seemingly obvious, isn't it?) Step is not done, but rush to build schemes and code, code, code ... then there is a big chance that this work will fly away to the basket! And as a result, you and your team, and your customers will experience great sadness. Ask yourself this question not at the end, but at the beginning of your “race”.
How to ask such questions? When and under what circumstances?
We formulate more strictly: in the framework of what processes, who and when raises such questions, as well as who is obliged to find answers to them that are understandable to all participants.
There is clearly at least one conclusion: these questions need to be puzzled to the starting point of the project. And even until its initiation. “But how is that?” - the question may arise: “We have long been accustomed to, that all IT activities are carried out in the framework of projects, and in the case of flexible methods - in the framework of sprints”.
This is where the interesting begins ... Let's hear what the “leading dog breeders” of the IT industry say on this topic - that is, organizations creating and disseminating various standards and reference practices.
So, OpenGroup recently released the concept of IT4IT . The IT operating model presented there includes a set of four basic “value chains” (VAD). One of them is “Strategy to portfolio”, within which a “portfolio of projects” is being formed, starting from what we want to see (target vision) and from the as-is situation (current architecture). Thus, a bridge to our desired “picture of the future” is built through the IT strategy and project portfolio.
/ It's time to ask yourself about how is it customary in our company to form a “project portfolio”? How are projects generated? At what stage are architects involved in this process? Who makes the decision to launch a project? /
Thus, the right way looks like this:
First, the target architecture ... More precisely, first the business strategy, then the target architecture that supports it, then the IT strategy, which reflects the transition from the current state to the target one, and finally, in accordance with the IT strategy, the formation of a portfolio of projects.
That is why the architects at the enterprise so persistently speak about the target, about the need to match the projects to its channel, about the need to fix deviations (temporary and workaround solutions), etc. This is their direct responsibility. This is their job. And it is their responsibility. And for them it is important that conversations about architecture are not infinite in nature, but ended with quite definite delivery - and certain (fixed decisions).
Does this happen often?
No, of course ... Mr. Chaos interferes in our harmonious system. More precisely, the people who create it themselves, consciously or unconsciously. However, it is not necessary to choose - and we also need to somehow exist in the circumstances offered by life - uncertainty, inconsistency, confusion, etc.
Let's try to figure out how everything happens, and what can be done about it.
We can talk endlessly about the target architecture (as well as about love) ... And therefore, it is important to fix a certain vision - to get a “picture of the future”. Or several options - several “pictures”.
Why is it important to fix? It would seem an obvious question, but oddly enough, a lot of spears break around it.
Because - the target architecture is our "support from the future." Imagine - what chaos will arise in our portfolio of projects, if it changes all the time?
Who is engaged in a similar study and is responsible for the quality of the result? Of course, an IT architect is his area of creativity, influence and responsibility. At the same time, he communicates with a large number of people, collects and processes a lot of information, studies existing analogues, tries something. Finally, it offers a kind of holistic solution - an architectural concept. It is presented for further discussion and approval as a target architecture - first in a very general sense - as a concept or vision.
When the target vision has appeared, you need to try to make sure that all powerful people (they are called “stakeholders”) see in it some value for themselves and come to an agreement on it. Thus, the criterion for stopping this “fascinating lesson” in discussing architectural concepts will be a reduction of comments from decision makers to a certain minimum.
As well as in any dispute, in the process of architectural debates people often overwhelm emotions. What is important to us? It is important on the one hand, not to miss any valuable comments, opportunities or needs. On the other hand, to direct the process in a constructive direction. Those. It is necessary to translate all judgments into specifics. In other words, to demand justification - both from the speaker, who presented the option of architecture for consideration, and from the questioner. The level of "like - do not like" - not the best way to build a similar process, because he is weakly productive.
A good way is an approach in which some proposed solution is “tested for sustainability” - questions from the “what if ...” series. A look at 360 around this topic.
To streamline the activities of making such collective decisions in large companies use the practice of "architectural committees". People who are affected by this will be involved in them - from business to those responsible for IT infrastructure and system maintenance. And the concepts are approved there. Not always this process in practice looks optimal and effective. But other options have not yet come up.
You can go into the constructive, if
- do not involve extra people;
- allow for discussion comments within its competence (decision-making areas and responsibilities);
- provide only clear and specific arguments;
- have clear criteria for bringing issues to public discussion and understanding of the model / format of these discussions;
- to clearly moderate the meeting - to adhere to the established rules and avoid the “bazaar” (to introduce and consolidate the rule - only one person speaks at a time).
A lot also depends on the leading architectural meetings - how strong is his position as a leader in this team, how respected is this person, how he is able to build a collective polemic in the framework of the constructive.
There are examples of the best organizational practices - on how to build architectural processes, when and what to bring to collegiate discussions on committees, how to submit and process comments, etc. And there are companies where such processes are brought to life. But even the best reference practices will not work if people do not have the initial mood to agree, and the company does not maintain an atmosphere of mutual respect and trust for each other.
Here the question may arise: what to do if really such a mood is not currently traced? Can I change it?
Firstly, it is necessary to see and realize the problem, suspend the discussion directly on the topic of the meeting, since when people get into emotions the level of argumentation, logical arguments stop working.
The second step is to try to see the positive intention of a person who objects, as it may seem to us, very strange - for example, he transfers the focus of attention to another subject for him, leads him to the side, etc. And to see your own commitment, if this in turn begins to annoy you. If we “caught the moment” in time, and the passions have not yet reached a high level, we managed to “press a pause”, realize it and mentally formulate it, then it will be harder for us to “vytsepit for emotion” - this is already good.
The third step is to “return” his intention to the person, but in a positive formulation. Thus, he was not just told that “I can hear you,” but he was really heard and given feedback. It would be nice to write it down and promise to return to this important and pressing issue later. And ask permission to continue the meeting.
The severity subsides, the constructive attitude remains.
Of course, it is not so simple. Easy to write - hard to do. We need experience and training in communications and negotiations. This topic is very extensive, and it will not work out to reveal it here, just to slightly outline and create confidence that such approaches are there, they are workers, and if you like, you can find them, study them and work through them in practice (better with the help of an experienced mentor).
In short, we come to the conclusion that architectural practice is in fact a part of corporate culture, a model of decision making, a common style of organization and interaction of employees within it.
In other words, the level of management of IT architecture and strategy is one of the components of the level of maturity of the company as a whole, which shows its ability to sustainability and development.
I note that the "maturity" in relation to the company is not determined by its size or its age. There are quite large companies that do not have a high level of maturity: i.e. They do not seek to “understand themselves” - their business, their employees, their goals. And strategic initiatives are often formal.
While there are startups in which people quickly come to the conclusion that, for example, one class coding (if we talk about the IT sector) is not enough - some organizing and directing force is needed.
And there are real examples of this. Recently, my architect friend was invited to participate in a similar project, in which good developers are already working, working with drive and interest, on new technologies, etc.And at the same time they say: “it somehow strangely comes out - code-code, but somehow ... it is not clear what result we are moving towards.”
In other words, a company can at an early stage come to a fairly high level of maturity, which increases its chances of being successful. And, moreover, and perhaps even more important - it increases the level of pleasure to work in such a company.
Now they write a lot about the fact that banks are facing competition with IT companies. And the leaders of banks are beginning to quickly reorganize management practices for IT - introduce flexible methods, buy IT start-ups, etc. But it does not make them IT companies. Why?Because people who work in google or amazon will not work in banks. This is not "their format." And it's not about the formal methods of managing the development and management of projects. Compare approaches to working conditions, relationships in these companies, ways of doing business, etc. What is the difference?These are companies of different cultures, different “ways of life”. A bank is not an IT company, and never will be. (As well as the IT company will never be a bank). So why should banks ... not remain banks, exploring and developing their strengths? (And they, undoubtedly, have them, including in IT.) Instead of rushing from the extreme - to the extreme: we transfer IT to outsourcing as a non-core supporting activity, then we are preparing for competition with IT companies.
And this is directly related to the issue of maturity.
A mature company, no matter what size, age, capital level, geography it is, whatever industry it belongs to - knows “itself”, sees “its future”, understands its business, hears its employees. And he seeks to find and build his own path of development, rather than blindly copying and trying on someone else's self ...
Remembering the tale of "Cinderella" - no matter how much you want to marry a prince, you should not try to cut off your heel, trying to fit into someone else's crystal shoe.
Each company has its own talent, its own theme. A conscious approach to the development of architecture takes into account the specifics of the company, tasks, project, their uniqueness.
Architectural standards and frameworks
Now it's time to turn to standards. And following the precepts of the wise Confucius, to give clear definitions of the concepts of interest to us, so that the “ceremony and music” flourish, and the “said” will be fulfilled.
As part of the IT architecture, there are several detailed standards.
First of all, it is ISO / IEC 42010: 2007 , where you can find the following definition:
Architecture is the fundamental concepts or properties of a system consisting of elements, the links between them and the external environment, as well as the principles of its design and development.But the definition of the famous TOGAF architectural framework from the OpenGroup :
The architecture has two meanings, depending on the context:Why did I start talking about definitions in the context of frameworks? What does the term “framework” mean by itself?
- ;
- , , , .
The framework defines the methodology for solving a particular class of problem. From the word "method" - a repeatable approach, the use of which leads to predictable results.
What are their value frameworks? In that once found, perhaps by chance, a successful solution is realized and applied further in such situations. At the same time, the framework does not dictate the solution thoroughly and completely, leaving the so-called "extension points".
There are two complementary and multidirectional processes in the framework:
- generalization (generalization of experience) - on the one hand;
- adaptation (localization of reference practices to a specific situation, problem, company) - on the other hand.
Thus, following the frameworks, enriching them with our own identifiable patterns, we get an excellent ability to manage development.
The ability to develop is a very important quality for a company, especially in times of crisis, because allows companies to remain competitive in the face of uncertainty and variability.
It is no coincidence that the requirement of "adaptability" is increasingly heard in relation to IT organizations. Sometimes this leads to unreasonably high expectations - to be able to solve completely different tasks “from one box”. This is not always justified. There is a more efficient way - to use the component architecture, without overloading tools and technologies with unusual and redundant functionality for them. This option is much more transparent and stable in use. But it also requires costs - it is not enough just a narrow knowledge of a certain one system - you need to combine many systems, integrate into a single IT landscape.
And the role of the IT architect, his task - just to help in this process. He does not make decisions alone, he collects and presents information in such a way that it is understandable to many people in the company - from business to engineers - i.e. prepares the ground for a collective decision. This does not mean that he should not have technological knowledge - just the opposite - the practice of working with technologies is one of the key aspects of his work. But as will be shown later, it is far from the only one.
So, the key meaning of architecture and the key tasks of architects is to determine the composition of components, their responsibility and interrelation, starting from a specific applied task that we solve.
In my opinion, this is a completely worthy mission, requiring various foci of attention and diverse competences - both technological and systemic, as well as communicative and organizational.
Finishing the topic with the definitions, I will give one more thing from Oracle , which, it seemed to me, very well reflects the essence and depth of the subject:
Architecture is a method and organizing principle that aligns functional tasks and business strategies with an IT strategy and execution plan.
Who is our customer and what wishes he may have expressed and unspoken
Like any artist who solves a problem posed by someone, the architect has ... right - the one who put it - that is, Customer! Who can be such a customer and how the “process of ordering the architecture” may look like depends on the IT organization's approach to organizing IT processes and can be a topic for a separate discussion.
Anyway, the Customer has, first of all, a certain need which he needs to "close". And he may also have his own ideas and his own “vision” on this score, which he, too, may be interested to realize.
For example, working in one bank, I received such an order - “... and also I would like the vault architecture to be such that the vault performs both operational and analytical functions ... in short, you need real time storage!”
It puzzled me a little, because This is a rather atypical and difficult requirement for systems of this class, but as they say, the task has been set - it must be done. As a result, a concept emerged that was slightly different from the original one — not “real time”, but “just-in-time” (the idea was borrowed from the famous principle of organizing production at Toyota - “just in time”). Thus, the initial requirement was somewhat relaxed and more realistic in terms of technical implementation, while the Customer was satisfied with the way his initial “vision” was taken into account.
Thus, no matter how formal and strict our field of activity may look, we need to know and even “feel” the Customer, his wishes and needs, his fears and even some negative experience. And we need to be able to present the concept of the solution in such a way that he wants to “buy” this product - i.e. so that the presented “picture of the future” eventually (perhaps after a series of discussions and discussions) coincided with his expectations - and he wanted to move, to invest in this direction.
It is necessary to note one more, in my opinion, an important detail. In addition to the requirements expressed by the Customer in an explicit form, there is always a set of “default” requirements - those that are implied, but not explicitly stated.
A professional always keeps an eye on his entire field, he controls the situation, he knows more and deeper about it than his client. Otherwise, the client would not have addressed him. And he must always remember that he is a professional, and he has a responsibility.
Thus, the recently released “Everest” film very concretely shows the tragic consequences of the situation where the pros blindly follow the client’s “wishes”.
Here another “hackneyed” term pops up - customer orientation.
Yes, of course, to know, to understand, to respect the internal client is necessary. But the performer is always responsible for the result. And more professionally - to refuse the client something, even to go into conflict, rather than let events happen, the consequences of which can be fatal.
And again we turn to the field of construction and repair, all familiar and intuitive. Any self-respecting specialist - plumber or electrician - will not be under any pressure from the client to implement the project with violations of technical standards. And lead a clear argument.
So why should IT be any different? Perhaps the consequences will not be so dramatic. But if we can say with enough confidence about the risks, we need to say about them. It will be honest and respectful towards your customer.
The customer can afford to live for today, all sorts of “quicwins”, to get involved in one super-innovation, then another, to be captured by trends and fashion trends that technical marketers so skillfully represent at various conferences and events from IT vendors.
An architect, while remaining a professional with a “cold nose,” should be able to look at 3, 5, 10 steps ahead. And what's more - to be able to switch the view of your client to the future. Trying to come to a common understanding, to a joint picture of reality, to which I would like to come in the foreseeable period, which I would like to follow and invest efforts for its realization.
Architecture is about the future ...
It is in this context that later in the 2nd part of the article I will put the strange question: “What is good architecture?” However, it does not look so strange considering all the above. Since He focuses on some “boring” things, which, however, will save our system, our client, from unwanted scenarios for further development.
Source: https://habr.com/ru/post/276527/
All Articles