This initial posting is to set up the practice of Zen and the Art of Enterprise Architecture. I am often asked the question: "How did you become an Architect?" Although many in the IT industry have taken the George Costanza approach and just slapped the title "architect" on their business card, I did not.
I could discuss my own series of milestones and accomplishments during my career, but that is probably best suited for a résumé or a LinkedIn profile posting. What would be far more compelling, I had thought, was to describe my journey through a series of "ah-ha" moments. These are the moments where small ideas start to coalesce, start to mature, and grow. This process in chemistry is known as crystallization.
One cannot become an architect by merely studying and presenting about it, one has to live it. What makes an architect credible and successful is experiential learning. Zen practitioners describe this as the "path of enlightenment" where less emphasis is placed on theoretical knowledge and dogma, and more emphasis in the direct experiential realization. Therefore, to be good at the practice of architecture, one has to get their hands dirty; one has to live through the results of their efforts, and digest both good and bad. Ultimately: you have to experience your architecture realized. How did the architecture influence design decisions? Did it foster or hamper the implementation process? Was it valued by your stakeholders? Did the architecture ease the burden of administration, configuration, and operations? Drive business results? Cost efficiency? Did it work?
Another aspect of Zen that is appealing is that one has to accept the world as it is, and promote harmony. Architecture is all about finding harmony given the multitude of stakeholders and their concerns. Understanding each constituency's perspective or view of what the team/group intends to deliver is absolutely vital to delivering a successful solution. Frameworks and process are a component of this, but an architect's style and manner of communication are also key competencies that need to be nurtured.
The Microsoft Solutions Framework Team Model is excellent in describing what it takes to assemble the right team from a structural perspective, but how do you get people to behave in a way to get them to execute is an acquired skill. That will be a topic for another blog.
This blog is about my own crystallization moments in my journey.
During my college studies, I enrolled in a philosophy class focused on the future of computer technology where I was introduced to the beauty of duality and art of paradox. Consider the paradox "I always lie." There is no way for a computer system to evaluate this phrase. The true can be false, and false can true. Therefore one has to avoid speaking this phrase or never have the phrase come up for evaluation. You have just divided by zero, game over if even attempt to evaluate. Circumlocution.
In this class, I was introduced to Gödel, Escher, Bach: An Eternal Golden Braid by Douglas Hofstadter. As the Hofstadter points out, each of these "masters" had common themes of creativity in their works even though their domains where quite different. One was a logician/mathematician, an artist, and a composer. This idea of common theme between art and science awakened something deep within me. I was a very left brained kid. I excelled in math, science, and history; the classic study of facts. I was never strong in the arts, or anything remotely close to studying any works of art (or romantic studies) for that matter. Here I was as a student at Northwestern University's engineering school learning my craft by studying electrical engineering and computer science, and the idea of contemplating the link between technology and art made my mind spin. I learned that etymology of the word technology is from Greek. The "techne" part of the word is often translated as "art" or "craft." I was conflicted or was I? I had my first Zen crystallization moment on duality and paradox.
Early in my career I had the role of a software manufacturing engineer. At that time programmers were measured by their output, which was the number of lines of code produced. What seems completely ridiculous today was not so crazy back then. I remember thinking, how does one evaluate which chunk of code is better? A piece of code that is simpler and produces the identical result is surely better? It annoyed me that I was not evaluated on the elegance (and the documentation) of what I had produced, but solely on the structure and quantity of the code. I had the assignment of updating a piece of software, the code was awkward and not modular enough to accommodate updates easily, so I had to rewrite. It was fewer lines of code, a bit more modular, and made my variable names more descriptive.
My customer had noticed the performance increase from the code that I had replaced. My software engineering manager had a very different perspective than my customer. Then I had a received a complement from a peer of mine, a software maintenance engineer who later had to modify my code given a business rule change. He came to me and said something similar to, "It was very easy for me to add this new 'thing' that the customer wanted. I was able to get this out the door fast!" I remember smirking at my manager and remembered the quote that was made to Mozart in the movie Amadeus in 1984: "Too many notes." Zen crystallization moment two:
I recently joined Microsoft. I escorted my date (who is now my wife) to the Asian Art Museum in San Francisco. While browsing in one of the galleries I noticed a huge, I mean HUGE painting. This painting was a Chinese landscape painting done in the traditional style called "shanshui". If you have ever seen one that is done in the traditional style, you would immediately notice colossal landscapes of "mountains and water". The people or animals in these paintings are usually very small, like accidental brushstrokes being dwarfed by the mountains, rivers, and trees around them. I thought to myself, why would the artist make the "subjects" of his/her paintings so small? The art that had enjoyed from the Impressionism movement had the subjects usually front and center, perhaps stood out by use of color, or was made to be larger than the rest of the environment; a significant difference between eastern and western approaches to art. I had later learned from one of my colleagues (who was born in China) was that Westerners chose to live in a world that is simple, well structured, and measurable, where the Chinese accept the dynamic nature of the world. Zen! The Chinese shanshui style emphasized the beauty of the environment and the subjects act or react based on their interactions with the environment. As a new professional services consultant within Microsoft, I had to rethink my approach to IT solution design. I have to learn how to be consultative rather than just go build. Zen crystallization moment three:
I became more intrigued with the concept of IT and Enterprise Architecture. The word architect also comes from the Greek language. The "tec" part of the word is interesting as it means "builder" and the "arch" stems from the word "chief."
A great experience is to actually walk (not drive) across the Golden Gate Bridge. This allows one to appreciate the beauty of the bridge and the emotion that is stirs, and then of course the engineering achievement behind it with its structure and how the cables where designed, etc. Form and Function. So what language would I use to describe this? What is the common language of IT or enterprise architects? Zachman? UML? TOGAF? No. Let's use simple language structure that we learn in elementary school. The subject is the bridge itself and its structure The verb is the how the bridge makes us feel or how it behaves, both in good times (sunny days) and bad times (earthquakes). The object of the bridge is how it functions with respect to people and transportation. Going back to the last crystallization moment of context and the Chinese landscape painting, I had felt that I had devoted perhaps too much time on the "subject" and not enough time understanding of the "context" and the "environment." Thinking about the art of language, the subject is static. What gives meaning to a sentence is the verb. Perhaps I have spent too much time focusing on the answer (THE SUBJECT) which is the ultimate structure of the design, the components, the actors, the code itself. I need to spend more time on the dynamic portion of the sentence, the behavior. What will it do? How will evolve? What external influences may change it?
The Roman architect Vitruvius declared that a "good" building should satisfy three principles of firmitatis, utilitatis, and venustatis; which translated from Latin, into durability, utility, and beauty. These all involve subjects (durability), verbs (beauty), and object (utility). Zen crystallization moment four:
After presenting at Microsoft's internal TechReady conference on the Zen of Architecture, I was encouraged by an attendee to read the book Zen and the Art of Motorcycle Maintenance, by Robert M. Pirsig. This book explores the metaphysics of quality. Pirsig describes an experience through a fictional character who has numerous philosophical discussions on a particular motorcycle journey on the topics of knowledge, emotivism, and the methods of science. The book inspired me to consider the question: What makes a quality architecture? What is a good system architecture? Permit me to focus on the word system. Search for "system qualities" on Bing, and the number of "-iliites" or system qualities is staggering. I would venture a guess that it is impossible to architect a system with all of them in mind. Some of the system qualities perhaps are more related to design and implementation. Not that these are not important, but what good architectural qualities would enable the right system design and implementation qualities. If I were to build a durable, beautiful, useful solution what qualities would I like to have? Is there an example of a good system? Nature provided the answer. Ah-ha: The Human Being.
Evolution has a remarkable way of forcing architectural quality into a system. So what qualities have made humans so successful?
Fifth Zen crystallization moment:
The Cloud is a Dynamic System. Our current static system approaches to architecture no longer apply. Why is it different?
Single System Engineering
System of Systems Engineering
Development of an IT solution to address or meet a grouping of stakeholder concerns with defined service levels.
Development of integrated IT solutions to leverage synergy.
Architecture is established earlier in the solution development lifecycle and remains static.
Dynamic configuration as environment changes using service orientation.
Develop specific interface requirements to promote integration
Use of standardized methods and protocols to promote interoperability.
Availability, Reliability, Performance, Secure, etc.
Agility, Resiliency, Efficiency, Partitioned, Integrated, Innovative
Long drawn out Envisioning and Planning phase to determine IT solution needs
Intense and rapid Envisioning and Planning phases followed by continuous adaptation and experimentation through iteration.
Less influenced by environment and the system itself
System highly influenced by other systems and environments
Failure isolated and fault isolation is easier.
Can lead to large failure, and fault diagnosis is challenging.
Build to resist failure by assessing risk then by deploying countermeasures.
Built by accepting that failure, and doing active risk management by proactively mitigating risk and use fast acting contingency plans in the event of failure by invoking processes and automation.
So what does it take to design an "architecture" for a complex dynamic system? This requires competency in the disciplines of abstraction, modeling, analysis, complexity theory, and system thinking.
An interesting notion about cloud computing is that its characteristics around quality are defined from the consumer's perspective not the provider. Microsoft being a software manufacturing company, this places us in a strange and potentially awkward position. We are used to being the provider of software, and we can talk about features and how great they are until we are "green, yellow, blue, and red" in the face (not necessarily in that order). Customers are now telling us, we want to pay for what we consume, and it better create an experience that they value. We now need to understand the holistic nature of quality from provider and consumer together.
What is most interesting about this for us in our world today is that most software/IT architects tend to start to design features, components, and devices of the system first. We want to know what we are going to build immediately, so we spend energy focusing on the active structure or the subject of the solution. Remember my crystallization moment at the Asian Art Museum? Context is everything. The subject the picture is small relative to the scene the entire painting of the Chinese landscape. As a software provider, we focus on the subject: features, components, personas, roles, etc.
Well what about building IT systems or solutions that support business functions and excite the end-user, isn't that the way it is supposed to be? Understanding the behavior, the verbs, of what the business or the consumer wishes to accomplish or does through their processes and interactions. Computational verbs are abstraction of verbs in natural language that are used by computers. They are used to model the actions or processes [behavior] represented by the verbs in natural languages into mathematical formula via qualitative analysis of dynamic systems.
Lastly, I feel during my 20 years in the I.T. industry, we have been overly focused on the T instead of the I. I was reminded by a customer whom I was consulting for that gently reminded me: "It's the data stupid." Information/data is the object. Our structures combined with behaviors manipulate data.
So bringing this all together, there are some very interesting parallels between classic architecture, IT architecture, philosophy, art, and analysis methods are show below.
Enterprise Architecture (ArchiMate)
Zen and the Art of Motorcycle Maintenance (Pirsig)
Active Structure (People, Devices, Interfaces, Components)
Subject Focused (Static)
Behavior (Services, Process, Functions, Value)
Verb Focused (Dynamic)
Passive Structure (Data, Information)
The cloud is an opportunity for IT professionals to develop dynamic systems that spur innovation, lead to efficiency, improve time to value, resilient in the face of negative change, adaptive in the face of positive change. These dynamic systems also have to strike the right balance of partitioning and integration to work cohesively within the system and with other system.
Crystallization moment six defining architecture based on IEEE 1471/ISO 42010: