English | EN 
Based on my work on Beautiful Delivery with autonomous cross-functional teams (for more details, see Use Beautiful Delivery to Speed Up Your Digital Transformation), I have set out to define the different roles in a bit more detail. This time I will focus on the Architect.
The main responsibility of the Architect is to make sure that the end result rests on a solid technical foundation. Her mission is to apply core architecture values and principles (for more details, see the Architecture Manifesto), and make sure business objectives are translated into contextual, conceptual, logical and physical architecture components. That traceability is how she makes sure that each piece of technology is applied with a purpose, and she is aware of the impact of technology innovation and how it impacts businesses.
The Architect defines the architecture principles for the product or service and also the non-functional requirements, which include security. She also sets up the governance and configuration management, and the primary goal is to automate as much as possible. Every manual step, like a manual approval to put in production, need to have a very good reason defined, or it should be automatic.
One of the most important tasks of the Architect is to set up the digital platform, preferably in a public cloud, and using a reference architecture. Everything will eventually run in a public cloud, and therefore there needs to be very good and continuously verified reasons to use any other solutions (on-premise, private cloud, etc). There are a number of valid architecture options for building a digital platform, but the ambition should be to move to a SMART architecture (for more details, see Building a SMART Architecture with Serverless).
Just like all the other roles in an autonomous team, the Architect has to be hands-on, so another task for her is to coach the actual implementation. This means that she needs to know how to code, and it doesn’t matter if she was coding ten years ago, the tools and the languages change so fast now that she needs to code regularly to remain relevant. An Architect that doesn’t code is not much use even on the strategic level. Thanks to modern cloud tools, it’s easy to put together an example of how a sound architecture can be implemented, and that is the best way to communicate with developers. Therefore, when the architecture design is done, it’s a good idea that the Architect implements a first “cross-section” of the solution. That means a very narrow part of the functionality, but that goes all the way from the touch point (web, app, bot, etc) all the way to the integration with back-end systems or external services. It will make it much easier for the developers to understand and apply the architecture, and this also means that the Architect can coach the developers continuously.
Another very important task of the Architect is to define master data and the service interfaces. In contrast to traditional MDM (Master Data Management) and SOA (Service-Oriented Architecture) initiatives, which were often multi-year projects with very low success rate, this task is about defining the master data and service interfaces in real-time as the user stories are implemented. So instead of trying to coordinate between many parties to define a common truth for everyone, the focus is on the specific functionality that is to be implemented but still having a long-term view on how data and service should be defined.
When the Architect is more experienced, she also works on a more strategic level, and coordinate between the autonomous teams. She has the ability to explain complex technical solutions in a simple way, and can, therefore, advises executives on how to transform themselves, which drive the digital transformation. She views matters from a customer-centric perspective and reasons outside-in with a focus on time to value, and she captures the mastery of experts and shares them as patterns and principles. She is also often the one that evaluates new technologies.
