The movie The Matrix made it clear: The Architect is powerful. How to be(come) and IT architect? What do you do, what do you need to know, is it fun and why? Using real world examples, core principles and useful tools, this session introduces the subtle art of designing and realizing flexible IT architectures. Taking a step back to get and create an overview, frequently asking why to get to the real intention, bringing aspects such as cost, scale, time and change and business strategy into the design and bridging the gap between business owners, process managers and technical specialists. One way to define the responsibility of an IT architect. In this session, we will discuss what is expected of the architect and what you need to do for that and what you could use to get it done. How do you get started as an architect, how to grow in that role? We discuss a number of real life architectural challenges and solution design. And discuss a number of architecture principles, patterns, and powers to apply. Never stop programming – but perhaps rise to the architecture challenge too. Notes: Many IT professionals aspire to become architects. Many architects wonder what it is they have to do. After 27 years in IT I find I have slowly and steadily moved into a role that I can probably use the label architect for, although still with some reluctance. What exactly does that mean – IT architect? While I may not have all answers and the ultimate truth and wisdom, I do have many architectural challenges to discuss and some core principles to share and a number of tips, tricks and tools to recommend that will help anyone get started or grow in a role as architect for software and IT systems. Elements that make an appearance include cloud, agile, DevOps, microservices, persistence, business, powers of persuasion, diagramming, cost, security, software engineering, data. Outline: – two real world examples (one new business initiative, one running and struggling project) and how to approach them with an architect's mind – core principles to apply , patterns to us, what to unearth (the power question of WHY) – architecture products: what do you deliver as an architect; how do you ensure agility? – how to be effective? bringing your design to life – communication with stakeholders/powers of persuasion, monitoring adherence, being pragmatic but not lose grip; – anecdotal evidence from several small and large product teams – the good and also the ugly (architectural oversights and the consequences) some specific answers to address – how much technical knowledge and programming skills does an architect require? What other knowledge is required and how to stay on top of your game? how to get going: first steps towards be(com)ing and architect?