Вот для затравки первая часть первой главы. Посколько ее дают скачать за просто так надеюсь можно и тут привести весь текст
As we have seen so far, Microservices give us an a lot of choice, and also a lot of things to trade off against each other. How do we go about making these decisions? With the faster pace of change, and the more fluid environment that these architectures allow, the responsibilities of the role of the architect also has to change. In this chapter I’ll take a fairly opinionated view of what the role of an architect is, and hopefully launch one final assault on the ivory tower. Inaccurate Comparisons “You keep using that word. I do not think it means what you think it means.” — Inigo Montoya from The Princess Bride Architects have an important job. They are in charge of making sure we have a joined up technical vision, one that should help us deliver the system our customers need. In some places, they may only have to work with one team, in which case the role of the architect and technical lead is often the same. In others, they may be defining the vision for an entire programme of work, working with multiple teams across the world, or perhaps even an entire organisation. At whatever level they operate at, the role is a tricky one to pin down, and despite it often being the obvious career progression for developers in enterprise organisations it is also a role that gets more criticism than virtually any other. Architects have more ability to have a direct impact on the quality of the systems built, for the working conditions of their colleagues and for their organisations ability to respond to change than any other, and yet we so frequently seem to get this role wrong. Why is that? Our industry is a young one. This is something we seem to forget, and yet we have been only creating programs that run on things that we would recognise as computers for around seventy years. As such, we are constantly looking to other professions in an attempt to explain what we do. We aren’t medical doctors or engineers, but nor are we plumbers or electricians. Instead we fall into some middle ground which makes it hard for society to understand us, or for us to understand where we fit. So we borrow from other professions. We call ourselves Software “Engineers”, or “Architects”. But we aren’t, are we? Architects and Engineers have a rigour and discipline we could only dream of, and their importance in society is well understood. I remember talking to a friend of mine, the day before he became a qualified architect. “Tomorrow” he said, “If I give you advice down the pub about how to build something and it’s wrong, I get held to account. I could get sued as in the eyes of the law I am now a qualified architect and I should be held responsible if I get it wrong”. The importance of these jobs to society means that there are required qualifications people have to pass. In the UK for example, a minimum of seven years study is required before you can be called an architect. But these jobs are also based on a body of knowledge going back thousands of years. And us? Not quite. Which is also why I view most forms of IT certification as worthless, as we know so little about what good looks like. Part of us wants recognition, so we borrow names from other professions which already have the recognition that as an industry we crave. But this can be doubly harmful. Firstly, it implies we know what we are doing, when we plainly don’t. I wouldn’t say that buildings and bridges never fall down, but they fall down much less than the number of times our programs will crash, making comparisons with engineers quite unfair. Secondly the analogies break down very quickly when given even a cursory glance. To turn things around, if bridge building was like programming, half way through we’d find out that the far bank was now 50 meters further out, was actually mud rather than granite, and that rather than building a foot bridge we were instead building a road bridge. Our software isn’t constrained by the same physical rules that real architects or engineers have to deal with, and what we create is designed to flex and adapt an evolve with user requirements. Perhaps the term architect has done the most harm. The idea of someone who draws up detailed plans for others to interpret, and expects this to be carried out. The balance of part artist, part engineer, overseeing the creation of what is normally a singular vision. With all other viewpoints being subservient, except for the occasional objection from the structural engineer regarding the laws of physics. In our industry, this view of the architect leads to some terrible practices. Diagram after diagram, page after page of documentation created with a view to inform the creation of the perfect system, without taking into account the fundamentally unknowable future. Utterly devoid of any understanding as to how hard it will be to implement, or whether or not it will actually work, let alone having any ability to change as we learn more. When we compare ourselves to engineers or architects, we are in danger of doing everyone a disservice. Unfortunately we are stuck with the word architect for now. So the best we can do is to try and redefine what it means in our context.