I have spent the better part of the last three days in sessions at Microsoft TechEd listening to folks talk about: What is an architect? How do we identify them? Are they born or taught? Are there good architects and bad architects, what differentiates them? Why are architects seen as “a necessary evil” are they just overhead. What do they contribute? I apologize in advance for the lengthiness of this post but this is a core value point to me and I tend to get very wordy when an issue is near and dear to my heart.
The Why of it all - I don’t know, what are we really asking
Why are we asking this question? Are we trying to justify our existence? Are we trying to improve our profession? Is it a role or a title maybe both why do we care? Are we experiencing a midlife identity crisis? Or is it just growing pains? How many people in other positions do you know that are questioning: Who am I: What do I do? I have heard many definitions of an architect over the last few days ranging from software police to conductor and artist. If there was ever a career field in catatonic crisis this is it. Unfortunately I also feel compelled to offer up a definition of IT architect. While I could not come up with a single word analogy to describe or be synonymous with architect lets try a long winded definition. After all what we do is important aren’t we worth more than a single word. I suspect that few if anyone will like my definition but most will likely identify it as true.
Architect Defined in General
The architect defined - On a product development effort anyone who makes a decision that materially affects the financial cost, business value, technical infrastructure or technical implementation or direction is by default an architect making architecturally significant decisions and is acting in the architect role.
The Reality of it all – Often we just aren’t Empowered
This may or may not be “The Architect” who generally is the person anointed by someone, on high in a position of power, to be responsible for the architecture artifacts. In fact I would submit to you that in most cases the architect on projects is rarely The Architect and there in lies our problem. There is not a clear identification of roles and responsibilities along with the power to veto. Everyone is an architect because throughout the SDLC each individual contributor more likely falls within the scope defined above at some point. From the Customer, Project Manager, Sr. Developer to the developer and lets not forget management in general.
Civil/Architectural Architects vs. Software Architects (Case Study)
As a simple non scientific case study let’s compare the civil architect to the software architect. Perhaps in examining why civil architects are successful we can glean a perspective into where our real problem lies.
On software development efforts unlike construction projects the power of veto for how things get built almost always lies with the plurality of those with the money and those managing the money. It is the reverse on a construction project the final say as to how to build the bridge, road or house is ultimately in the hands of THE ARCHITECT. Does he work within constraints financial and time related sure. Scope budget and time are ever present in almost any undertaking that requires developing / building something. This is because it is understood and accepted that the civil architect is the expert in the rules, code and laws regarding construction and more likely than not specializes in the specific domain in question. He is the de-facto expert on form function design and codification for the project and all acknowledge that.
So why is the civil/architectural architect so much more powerful than the software architect? The answer is simple: it has little to do with power and more to do with empowerment. Civil and architectural architects have been sanctioned and empowered with the responsibility by others outside of the project. These people insist the architect take responsibility for the design and direction. Don’t think for a moment that there are not carpenters, concrete workers, brick layers and others out there saying, “this is crazy why do it this way I know how to do it better”. They are there but I can guarantee you that none of them are willing to deviate from the blueprints handed down from the ARCHITECT. That is because the customer, the financier and the state insist that they have empowered the architect to design and architect the appropriate and safe direction for the construction of the bridge, road or house.
An Architects view on Architects
A good friend of mine who works for Microsoft and fellow architect (Denny Boynton) recently wrote an interesting blog on
The Role of the Architect. In this article he poses that there are many forces exerted on the software architect both internal and external to the project. In the face of these forces it is the fundamental role of the architect to blend technical capabilities, business needs and corporate cultural factors into a “Best Fit” solution for the circumstances.
In short the job of the architect is to understand the customer needs, business value, technical and operational landscape and weight these factors appropriately against the corporate and IT strategy to determine the correct course of action. He also notes that t is not the role of the architect to become embroiled in the “religious wars” that erupt around technology.
While I concur that religious zeal around technology is not appropriate in the context of defining a project’s technical direction. I disagree that it is the role of the architect to avoid or shun those technology conflicts. Unwillingness on the architect’s part to wade into the fray and shout above the fray “Follow Me” is an abandonment of his responsibility to provide guidance and direction in his area of expertise and to make sound judgments for the technical direction of his organization.
The fact that “religious wars” are even taking place brings into question the abilities of the architect. At the core one of the fundamental duties of the architects’ is to provide the vision for the implementation, adopting and exit strategy for technologies within the corporate framework. Additionally, justification is needed identifying how they relate to the corporate business and IT strategy. It is also the responsibility of the architect to provide a clear and concise vision of how technologies are to be used for business value and how that also relates to the corporate bottom line. In this light the development and management community should no longer have a need or desire to engage in “religious wars” as everyone can clearly see how technology is to be leveraged for business benefit. At worst there should only be minor skirmishes around the overlapping areas of the capability models that can easily be resolved.
Types of Architects
From my comfortable armchair I look out on the domain that is information technology and see that we go to great lengths to differentiate the numerous types of architects as if therein lies the ability to rank them. There are no less that 12 types I can think of off the top of my head no doubt you can think of many more:
Enterprise Architect
Solution Architect
Application Architect
Data Architect
Integration Architect
Infrastructure Architect
SAP Architect
Microsoft Architect
Java Architect
Data Warehouse Architect
Domain Architect
Network Architect
As you look at these title/roles, daily hats you wear you may notice that they all have one thing in common the word ARCHITECT. The word architect in each of these roles is the noun the word(s) immediately prior is the adjective enhancing and adding specialization to describe the type of architect. In the end we are all architects and as such should be able to define a common set of activities, goals and actions that define us. I would submit that in the final analysis there are really three kinds of architects
Empowered Architects – Those who are given the power to effect change within the enterprise domain or problem space.
Consulting Architects – Those who provide recommendations and best practices direction only, but cannot effect change.
Ad Hoc Architects – Those who in the absence of empowered architects make decisions based on the problem presented to them irregardless of the enterprise domain or problem space.
Final Observations
In closing let me posit that the real issue that plagues our profession is not; what is an architect or even who should be an architect? No matter what criteria we place on the table as the hurdle to overcome there will always be good bad and indifferent architects just as there are good bad and indifferent teachers, doctors lawyers, CEO’s …. What we are missing are the certifications, standards, and characteristics that define what makes an architect and architect. You do not grow up to be an architect by putting in your time as a developer and graduate to architect by virtue of time in service or it’s the next promotion step. I contend that we can fairly easily identify common actions, traits and disciplines that are indicative of the people we what to give the title and role of Architect to. I provide those listings below for all to consider as my closing words on “What is an Architect”. I will leave the measurement and certification question to another day as it is much more politically charged even than this question.
Actions that indicate Someone is an Architect
- They consider the enterprise, business and technology landscape when crafting and directing the solution so that it adds business value while reducing impact to the core infrastructure.
- They refrain from engaging in the defeatist arguments of technology bigotry while striving to seek a middle ground and achieve a balance of technologies in the enterprise.
- They are the consummate politician employing all of the strategies of negotiation and influence to achieve goals that further the companies’ strategic objectives through the use and application of all technologies in their arsenal.
- There are above all scholars and teachers of the discipline of architecture exuding a desire to foster better understanding among their peers and others they council and provide guidance too. The hunger for knowledge and actively seek out opportunities to broaden their technical portfolio.
Traits that Identify Someone as an Architect
- They understand and support technology decisions based on a process that maintains a holistic view of the applications, solutions platforms, and business processes that enable the achievement of business goals. Planning the future technologies based on alignment to business strategic goals.
- The embrace Architecture as the discipline of thinking and planning how Information Technology implementations will support business strategies now and in the future with the least amount of friction
- They accept responsibility for developing, maintaining and envisioning the technology direction that best enables the priority business activities of their company and facilitates the adaptation of technology to the changing business needs.
- They work with business units, application development and IT Operations to ensure current, short and long term goals are being realized.
- They foster architectures that include the frameworks, networks, deployment configurations, domain architecture, and supporting infrastructure that form the technical architecture for the enterprise.
- While they specialize in one particular technical area, they must always maintain currency in each of the core disciplines. Without this broad general knowledge, they will be unable to design effectively, as problems and opportunities will not be evident.
Disciplines
- Business Strategy.The role of IT is to make businesses more successful in meeting their strategic goals. An Architect must be able to understand those goals as expressed by the client, and translate them into winning IT strategies. The role of the Architect is not to help the client develop their strategy, but to help the client execute it with technology, process and IT operations as leverage points to deliver strategic value.
- Financial Management.The Architect must be able to analyze, in more than a superficial way, the financial impact of current operations and of proposed changes. The Architect’s job is to show senior management how to evaluate the options presented from an investment point of view.
- Business Process Design.The Architect must carefully consider business processes as part of the design process; after all, the goal is to make the processes more effective and (usually) less costly. Without understanding how to think of business processes, and how to change them, the architect will be unable to go beyond the level of talented craftsman.
- Organizational Dynamics. Frequently technology deployments fail because of inadequate consideration of the effects of the change on organizations. Organizations tend to evolve, and at any given moment most organizations will reflect the hard-learned lessons of the last generation of technology. The challenge for the Architect is to help make the transition to new designs in such a way that the new design can be managed by the changed organization, and that the financial benefits predicted can indeed be obtained.
- Information Technology.Without a firm grasp of all areas of information technology, the Architect is doomed to mediocrity. The Architect must understand application design, the Internet technologies, database and data warehouse design, network design, and the many other aspects of information technology at a thorough, cross disciplinary level.
Architecture Design