About this Book
Many large enterprises are facing pressure from the rapid digitalization of the world: “digital disruptors” attack unexpectedly with brand-new business models; the “FaceBook generation” sets dramatically different user expectations; and new technologies have become available in the cloud to everyone with a credit card. This is tough stuff for enterprises that have been, and still are, very successful, but are built around traditional technology and organizational structures. “Turning the tanker”, as the need to transform is often described, has become a board room-level topic in many traditional enterprises: “we need new digital products!”, “we need to renew our tech stack!”, “we need to de-layer our organization!”, “we need to become agile!”, “we need to become digital!” are the battle cries that often emerge out of the board room. Not as easily done as said.
Chief IT Architects and CTOs play a key role in such a digital transformation endeavor. They combine the technical, communication, and organizational skill to understand how a tech stack refresh can actually benefit the business, what “being agile” and “DevOps” really mean, and what technology infrastructure is needed to assure quality while moving faster. Their job is not an easy one, though: they must maneuver in an organization where IT is often still seen as a cost center, where operations means “run”as opposed to “change”, and where middle-aged middle-management has become cozy neither understanding the business strategy nor the underlying technology. It’s no surprise then that software / IT architects have become some of the most sought-after IT professionals around the globe.
With such high expectations, though, what does it take to become a successful Chief Architect? And once you get there, how do you get support and keep up? When I became a Chief IT Architect, I wasn’t expecting any magic answers, but I was looking for a book that would at least help me not having to reinvent the wheel all the time. I attended many useful CIO/CTO events, but most focused on what the business wanted to achieve and little on how to actually accomplish it on a technical level. Having been unable to find such a book, I decided to collect my experience of over two decades as software engineer, consultant, startup co-founder, and chief architect into a book of my own.
What Things Will I Learn?
The five major sections in this book correspond to the aspects a chief architect has to tackle to effectively support a large IT transformation:
- The role and qualities of an enterprise or IT architect
- The value of architecture in a large enterprise
- Communicating to a variety of stakeholders
- Understanding organizational structures and systems
- Transforming traditional organizations
This isn’t a technical book. It’s a book about how to grow your horizon as an architect to better utilize your technical skill in large organizations. This book won’t teach you how to configure a Hadoop cluster or how to setup container orchestration with Docker. Instead, it will teach you how to reason about large-scale architectures, how to ensure your architecture benefits the business strategy, how to leverage vendors’ expertise, and how to communicate to upper management.
Are the Things Proven to Work?
As the title may suggest, this is a personal and somewhat opinionated book: it’s based on my daily experiences of two decades in IT, which led me through being a start-up co-founder (lots of fun, not lots of money), system integrator (made tax audits more efficient), consultant (lots of PowerPoint!), author (collecting and documenting insights), Internet software engineer (building the future) and chief architect of a large multi-national organization (tough, but rewarding).
I felt that taking a personal account of IT transformation is appropriate because architecture is by nature a somewhat personal business. In building architecture you can easily identify the architect from afar: white box - Richard Meier, all crooked - Frank Gehry, looks like made from fabric: Zaha Hadid. While not as dramatic, every (Chief) IT architect also has his or her personal emphasis and style that’s reflected in their works.
The collection of insights that make up this book reflect my personal point of view but are written such that the “nuggets” can be easily extracted and put to broader use. Architects are busy people. I therefore tried to package my insights so that they are easy to consume and even a bit fun to read.
Tell me a Story
If you are looking for a scientifically proven, repeatable “method” of transforming a technical organization, you may be disappointed. This book’s structure is rather loose and you may even be annoyed to have to read through little anecdotes when all you want is the one bit of advice you need in order to be successful.
I purposefully chose to structure the book as a collection of stories. As our world is becoming more complex and difficult to understand, telling stories is one of the best ways to engage and teach. Studies have shown that people remember stories much better than sheer facts and there appears to be evidence that listening to a story activates additional parts of our brain that helps with understanding and retention. Aristotle already knew that a good speech contains not only logos, the facts and structure, but also ethos, a credible character, and pathos, emotions. Emotions distinguish a story from a scientific analysis.
To transform an organization you don’t need to remember facts and solve mathematical equations. You need to move people. That’s why you need to be able to tell a good story. It’s fine to start out by using some of the attention-catching slogans from this book (“Zombies will eat your brain!”) and later supplementing them with your own stories. Stories get attention and evoke emotions - the best way to get people moving. Have you seen people cry and laugh when watching movies, even though they know exactly that the story is fictitious and all acting is fake? That’s the power of storytelling in action.