In-Depth
Traits of a Total Architect ... And All That Jazz (Part 2 of 4)
How a Total Architect is like a musician.
By Frank Bucalo, Enterprise Architect, CA Technologies
In my previous article, I cited the fact that a new role has emerged in the IT vernacular -- the Total Architect. These people have a reputation for successfully delivering computer system implementations in an industry with failure rates upwards of 75 percent. We cited Dr. Paul Brown's recognition that computer systems have become too complex -- across the dimensions of business processes, people, information, and systems -- to deal with those dimensions independently. Then I provided four real-world use cases -- representing each dimension -- where a project either did or would have failed for lack of a Total Architect.
This article looks at the role of the Total Architect by considering what traits Total Architects exhibit. The key words in the phrase "Total Architect" are self-explanatory. These people have deep knowledge and experience involving each dimension, hence the word "Total". Furthermore, like a building "Architect," they are able to deliver solutions that are both functional and beautiful. Furthermore, Total Architects talk of solutions that are "elegant" -- that is, agile, effective, and efficient.
Surprisingly, many of the Total Architects I have known have been accomplished musicians. The remainder of this article will consider the traits of accomplished musicians and relate them to traits required in a Total Architect -- hence "and All That Jazz." That's not to say that to be a Total Architect one must be an accomplished musician. Nor does it say that all accomplished musicians would make a good Total Architect. Merely, there is a high correlation in innate skills between the two groups.
Accomplished musicians must have a balance of left-brain and right-brain functions. The left brain has been tied to analytical and mathematical processing. In the musician, that means knowledge of notes, chords, and rhythms and their mathematical relationships. The right brain function has been tied to creativity. The accomplished musician takes the mathematics of music and adds artistic interpretation and even improvisation. So it is with Total Architect. They take their knowledge of the technology stack and add the context of the business requirements, the people and project constraints (such as time, cost, and quality) to improvise an appropriate solution.
As a Total Architect, I've been asked to "write what you know" so it can be replicated. The problem with this request is that it ignores the creative, improvisational part of the "Total Architect." That cannot be easily cloned. Many a time I've been on a plane, flying to a site where a project was faltering, without fully knowing what I was going to do when I arrived. Using the combination of right- and left-brain processing, I've typically been able to turn the project around and depart within two weeks. That involved a lot of knowledge, talent, and skills, but there's no question that in each instance I was creatively improvising, much like a musician.
Accomplished musicians must exhibit a degree of discipline. After all, while one can intellectually understand music, it is quite another thing to develop the technique and muscle memory required to perform intuitively at a proficient level. That skill takes countless hours of effort over years to develop. So it is with the Total Architect. Systems used to run on a single, contained, stable, and well-known platform. I remember people who made a very nice living for many years based only on a deep knowledge of Customer Information Control System (CICS).
Not so today. The technology stack and the corresponding layers have exploded. For example, I was creating a proof of concept once when I realized that from the time the user pressed "Enter" to the time the screen painted the result, the request went through twenty-two technical layers. Each one of those layers must be understood, configured, and tuned for the solution to function properly. Add the fact that the technology stack is constantly changing and with virtualization, grid computing and cloud computing, new layers are constantly being added. The Total Architect must be dedicated to constant and continual learning to develop and maintain the requisite knowledge to make systems work properly. That takes discipline and love of learning.
Accomplished musicians think abstractly. Have you ever wondered how a pianist can look at a page with thousands of black dots and somehow make sense of it? It is because the individual notes can be abstracted to scales and chord progressions that often repeat with slight variations. Using patterns and abstraction, the blur of notes can be reduced to a few concepts. So it is with the Total Architect. They can look at a system with thousands of lines of code and somehow make sense of it.
For example, a mutual fund company had a system to compare employee trades against fund trades to identify potential instances of "front running" (i.e., making trades ahead of the corporate trades to gain a profit -- a form of insider trading). The Securities and Exchange Commission (SEC) asked the company to also compare and report on trades across fund families to look for front running. The strictly left-brained types, who are typically concrete thinkers, reviewed thousands of lines of spaghetti code and concluded that the system would require rewriting to satisfy the SEC requirement.
A Total Architect stepped in and without looking at a line of code, concluded that if fund trades can be allocated to pretend employees, the comparisons would occur as written. A total of five minor changes were required and the system was up and in production within five days.
Accomplished musicians are detail oriented. I can hear you ask "Frank, I thought you just said that musicians were abstract." That's true. To perform successfully a musician must be both abstract and detail oriented at the same time. So it is with the Total Architect. This illustrates the "Totality" required for system implementation success and illustrates Dr. Brown's claim that implementations are too complicated to break into discrete parts. A typical example we encounter is with the strictly right-brained folks. A common phrase we often hear when defining system requirements with them is, "We'll use the 80/20 rule." This usually indicates a resistance to drive out the detail specific business rules required to automate business processes.
Think about a computer system that fails twenty out of a hundred times -- that would be intolerable. That's a little short of the requirements for Six Sigma: 99.99966 percent success. No, details are essential and cannot be avoided. That's not to say one must nail every detail prior to implementing a system. Rather, specific business rules can be defined for most cases as long as exceptions are routed to a human for processing using their expert knowledge.
Accomplished musicians recognize subtlety and shadings. In the musician's world, these represent such things as changes in volume, tempo, blue notes, and so forth. These transform cold, dead dots into a beautiful work of art. In the Total Architect's world, these might represent words or object relationships. For example, I was on a project where I listened to the business user and the developer both use the phrase "service level" in a discussion. They believed that they were communicating clearly, but I was able to discern that they were talking about two different concepts. An example of an object relationship subtlety might be discerning that a "customer" and a "potential customer" do not represent the same concept in the current business context and therefore should be modeled as separate objects.
Most importantly, accomplished musicians can perform. It's one thing to be able to discuss music and theory around it. It's quite another thing to play. The only criteria for identifying an accomplished musician is that they can play -- that's how you recognize them! My experience in the computer industry is that there are many who can talk about system implementations but few who can deliver (hence the 75 percent failure rate). They may have a big-name firm behind them. They might have an advanced degree from a prestigious institution. They might wear an expensive suit. They might present well. They might project a professional image and an air of deep knowledge and experience.
Although such traits do not preclude success, they also do not guarantee it. I can remember dealing with a firm that presented such an image, including a healthy degree of arrogance, but they repeatedly failed to deliver. Specifically, I remember using the phrase, "Once you deliver you can be as arrogant as you want." The only metric useful for identifying a Total Architect is that they have performed. They have delivered successful implementations many times. That's how you identify them!
In summary, accomplished musicians take their instruments, composed of strings and valves and keys and pedals and slides. They configure and quite literally tune them to perfection. They then combine them with the human factor to produce something magnificent that could not be achieved without a combination of finely tuned machines, human knowledge, and experience. So it is with the Total Architect. They deal with the hardware, the software, the network, and other aspects of the technology stack. They configure them and tune them to perfection, and combine them with the human factors to successfully deliver system implementations, and implementation success (like a well-crafted symphony) is a beautiful thing to behold.
Frank Bucalo is an enterprise architect at CA Technologies and an accomplished orchestral and jazz trombonist. Prior to his time at CA Technologies, he was an architect and a consultant with banking and brokerage clients. He is a member of the Global Association of Risk Professionals (GARP) and an ITIL Service Manager. Mr. Bucalo represents the new breed of "Total Architect" – knowledgeable and experienced across business, technology, and technology management domains. You can contact the author at [email protected].
- - -
Other articles in this series:
Part 1: How Total Architects Enable Project Success
Part 3: Hiring a Total Architect
Part 4: Putting a Total Architect to Work: Lean IT Implementation on Steroids