Let’s start with an example. Say that you have microservices components that issue HTTP  requests. For every HTTP request, you want to log, by using a common format, how long that  HTTP transaction took and the HTTP response code. Now, if every microservice did this  differently, there would not be a unified way of looking at all traffic. Another role of the  practicing architect is to build helper artifacts that are used by the microservices. Instead of  the governance process being a gate, it is an accelerator because the architects are  embedded in the teams, and work on code alongside of them. Now, the governance cycle is  done with the teams, and instead of reviewing documents, the code is the document and the  checkpoint is to make sure that the common code is being used. Not all teams are created equally. Some teams are creaking APIs like a factory, some are  thinking ahead to upcoming challenges, and some teams are a mix of the two. An advanced  team that succeeds in finding a way to automate a particular governance challenge is a much  more successful evangelist for that mechanism than any attempt to create it by a separate  governance team. Regarding the technical architect, it might seem that they have too many responsibilities.  They are responsible for application delivery and a part of the committee, and now you are  adding the additional responsibility of writing common code that is to be used by other  application development teams. Is it too much? A common way to offload some of that work is to create a dedicated team that is under the  direction of the practicing architect who is writing and testing this code. The authoring of the  code is not a huge challenge, but the testing of that common code is. The reason for placing a  high value on testing is because of the potential impact to break or introduce bugs into all the  applications that use that code. For this reason, extra due diligence and care must be taken to  justify the investment in the additional resource allocation. Your aim should be to ensure that general developers in the application teams can focus on  writing code that delivers business value. With the architects writing or overseeing common  components that naturally enforce governance concerns, the application teams can spend  more of their time on value and less in governance sessions. Governance based on complex  documentation and heavy review procedures is rarely adhered to consistently, but inline tools  that are based on standardization happen more naturally. 2.5.7 Producing multi-skilled developers Developers are expected and encouraged to be full stack developers and solve the business  problem with whatever technology is required. This situation puts an incredible strain on each  individual developer in terms of the skills that they must acquire. It is not possible for the  developer to know every detail of each technology, so the infrastructure learning curve suffers.  You are finding better ways to make infrastructural concerns the same among all products. In the pre-cloud days, developers had to learn multiple aspects of each technology, as shown in  Figure 2-12 on page 29. 28  Accelerating Modernization with Agile Integration