While there is still a lot of conversation going on about what it means to be a software architect, there are a few things that are true among all of us who wear the title "Architect":
- Architects are thought leaders, pushing the envelope on what's possible
- Architects provide the vision, guidance and experience that enable others to make that vision a reality
- Architects need to understand the technical and the business (practical) side of any project to provide the best proposed solution
Now, watch the following Monty Python "Architect Sketch" with these points in mind. It's not only entertaining (one of my very favorites from the Python troupe), but required viewing for anyone who purports to have a sense of humor:
Monty Python's "Architect Sketch"
Though John Cleese and Eric Idle are pitching "a block of flats," there are certainly many things that should resonate and seem familiar to those of us working in the software industry today.
Understanding the Project Requirements
This is one of the most obvious and most missed parts of working as an architect. There are several reasons for this:
- The architect doesn't understand what the customer wants, but doesn't know it
- The customer doesn't know what he/she wants, but doesn't know it
- The architect makes certain assumptions about the customer's intent, goals and technical maturity
- The customer makes certain assumptions about the architect's experience and level of knowledge
- The customer and the architect don't ask questions or challenge ideas for fear of looking unknowledgeable
Any one of these common situations can send a project off the rails before it even gets started, and usually there are two or three in play at the same time.
As architects, we need to understand the business drivers of the project in order to present the "right" solution to the customer. There's an old joke that says, "The only answer an architect needs to any question is, 'It depends.'" Well, to a certain degree, that's true. There are always going to be many different ways to solve a problem. Our job is to understand our customers' motivations by asking pointed questions and challenging them on things that don't seem to make sense, thereby enabling us to provide the best solution to meet their needs and avoid pitching an abattoir when a block of flats is what the customer really wants.
In addition, the architect needs to be self aware and not push a customer into a solution because he/she is afraid to admit they've missed something during the discovery phase of the project. I've never heard tell of someone being removed from a project because he/she was honest and said, "I must have misunderstood what you were looking for here -- let me work on an alternative solution," at the beginning of the project. I can imagine it would be very easy to get thrown off a team for spending several weeks developing only then to find out that the solution you convinced your customer was the "right" one is not going to get them what they need.
Thought leadership becomes a reality by taking your collective experience, diving deep into the customer's needs by asking the right questions and challenging the ideas that don't make sense and by listening as much as you talk. Self-criticality and honesty build trust and credibility.
Compromising the "Right" Solution
No one who has worked on even one project in their careers is unfamiliar with the multitude of external forces that can negatively impact a project's outcome. The customer wants the most business value from a piece of software for the least amount of money. Developers don't tend to care about cost as much as putting together solid code that works.
In the middle sits the architect.
It's not unusual for a customer to look to cut corners to save money on a project, especially if there isn't a real, tangible ROI attached to the final product. As an architect, we need to make sure we communicate the probable consequences of these cuts and make sure that we adjust the technical roadmap as a result. The fact is that the customer is not always right, and we need to make sure that they have all the facts about a decision before they make it.
At the end of the day, the customer is one paying for the project and we need to attentively listen to their ideas, but we must not passively let the make erroneous decisions. Our passion for building solid, secure and performant solutions has to be asserted in a way that serves our customer's best interests. This sometimes means pushing back on cutting corners, especially if they involve a "central pillar system," "recessed magnilium phalange groups" or "fire suppressant materials," i.e scalability, performance and security.
Politics and Technological Religion
It's been said that if you put more more than two people in a room together, politics becomes part of the decision making process. OK, I've always said that, but it seems too obvious for someone else to not have said it already -- I just don't know who.
Political struggles within companies are right up there with death and taxes on the "Things You'll Eventually Have to Deal With" list. More times than not, politics drives the decisions made concerning technology, the one area where it should be easy to purge political influence. I say that because it is very easy to quantify technical decisions. You can easily apply hard numbers to:
- Development resources required to deliver the solution
- Cost of new software and hardware to support the proposed solution
- Cost to integrate the new system with existing systems
- Cost of training to ramp developers' skill sets
- Projected cost of maintaining the solution over its life span
All this being said, I still see decisions made all the time based on political and technologically "religious" grounds instead of hard-core numbers. I was once talking to an architect who was working on performance problems with a JSP-based line-of-business application. He had the idea to build a WinForm application with .NET and see if he could improve on the 57 seconds it was taking for the JSP page to render a grid of data from a local database.
He got it down to 2 1/2 seconds.
When he presented the solution "bake off" to his management team, the conversation went a little bit like this:
Management: "How many records could be returned in the web app so that it would match the performance of the client-side 'test' you wrote?"
Architect: "About 250."
Management: "OK, change the web app so it only returns 250 records."
Clearly, politics and technological religion are so prevalent in that organization, management is willing to dramatically alter user requirements to stay on one technological stack and avoid the other completely, regardless of the hard facts in front of them.
As architects, we need to be aware of the these forces at work all around us. Ultimately, we have to consider the existing technology landscape within an organization and weigh the potential advantages and disadvantages of our proposed solution. As much as possible, we need to consider ourselves "technology agnostic" and truly consider what is the "right" architectural approach to meet the customer's needs.
Put simply, the architect should expect to deal with politics, but not participate in them.
"Free Masonry Opens Doors"
In the end game, being an effective architect is about integrity as much as it is technical skill. I've known many people over the course of my career that were my technical superior, but always struggled to fill the role of the architect on projects, due primarily to their overly focusing on implementation details.
Success is largely dependant on being able to take a macroscopic view of the project and the overall ecosystem in which it will need to fit. Having a detailed understanding of the requirements, being your customer's biggest advocate (sometimes in spite of their best efforts) and distancing yourself as much as possible from internal politics and technological "religious wars" will go a long way to letting you apply your technical expertise and be a successful architect.
Then you'll learn the secret handshake.