Ken Sipe, Cloud Solution Architect at Mesosphere and NFJS speaker discusses what it truly takes to be an architect. See Ken Sipe, along with 15 other industry leaders, experts and open source leaders at ArchConf 2016 or check out some of our training courses around the country.
What is an Architect?
At the surface, this question sounds like a simple one. Universally, developers and development teams know there is a role for an “architect”. Most corporations define a title for a number of people called “architect” and there are user groups and associations that cater to this group. One would think that the best person to define what an architect is and what they do is an architect. However if we ask 100 software architects what an architect is and what it is they do, we would get a large array of answers. What seems to be consistent, is that they lead developers, they have broad experience and have a large impact on the project, they wear sandals and the guys have facial hair.
It has been my observation that the role of architect differs so much based on the needs placed on the architect, which differ from project to project and from company to company. The role for an architect for a product such as JBuilder, is completely different than the role of the architect for eBay. The nature of software is complex. We are not just talking the difference between desktop and web application development.
Rational Unified Process (RUP) defines Architecture as “the highest level concept of a system in its environment. The architecture of a software system is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.” An architect would logically be a person who understands the higher conceptual levels of the system and provides rules, guidance and governance for the creation of the structure of the software and the bounds for which the smaller components will take form. In “Who needs an Architect”, Martin Fowler provides good reasoning why RUP’s definition is poor and purports that “expert developers working on a project have a shared understanding of the system design”, that the shared understanding defines ‘architecture’. Such is the case today, that the interpretations by the experts result in differences in opinion. It seems consistent with the struggles in the science community in defining what a planet is and if Pluto is a planet.
In a bold move, which based on already stated reasons will likely be met with challenges, I define architecture as all the non-functional requirements of the system. Everything that a user would not ask you for in a user story. There is room to define this as the architecture and design of a system; however then we will get stuck in the gray area of delineating the difference between architecture and design. Using this definition, I define an architect as the person who defines all the nonfunctional requirements and provides a solution to successfully mitigate those requirements. This would include scalability (such as there needs to more than 10 concurrent users), security, performance (such as we need a sub 5 minute response time), technical libraries, and system topology. Frequently the user does not provide development teams with this information, nor would we expect that. In the absence of this information, someone must stand fast and bring order where there is often chaos… and thus the need for an architect is born…
A good architect is vital to the success of a software system, (s)he seems to be the person or people who have all aspects of software needs in check. The number one issue of software development is accurately defining the software requirements and getting early and often feedback from the users. The second success factor is software integrity, which is maintained through the guidance of an architect (or someone playing the architect role).
Where do architects come from?
Unlike many other engineering disciplines that have a degree program, I know of no degreed program for software architecture. There are certification programs, through vendors and some universities.
So how do you “become” a software architect? The typical progression starts with the position of a developer. That developer gets good. Damn good! Management starts thinking… “Could this developer lead others to do as (s)he does?”… “If we could just clone that developer, our problems would be over”… and thus a developer is asked to choose a path, “Would you like to be a project manager? Or an architect?”
The more interesting aspect of this transformation is that regardless of the desired path, either role requires the developer to tap into skills that are completely different from that which made them great as a developer. Commonly, a new project manager or architect doesn’t meet the expectations of his/her leadership in this new role. Usually management and the architect become frustrated. The usual cause is that expectations are high based on prior observations of performance in an area of excellence; the bar for that experience is the threshold of expectations for this new role, regardless of the lack of experience.
With the assumption that you have travelled the path of a good senior developer, in other words you rock as a developer, this articles focuses on all the aspects of the role of architect that I have experience through my career.
Aspects of an Architect
Defines System Structure
One aspect of architecture is the ability to define and communicate software system structure. This can be defined a number of ways, the logical view, the physical view, the deployment view, system topology. Many systems such as simple web applications have a very common deployment view which negates the need for explicit articulation, where aspects of the system are assumed. However assumed or not, the architect has a vision of what each view looks like and can articulate it on demand. For aspiring architects, you need to be able to read and write UML. One suggestion… know how to read and write UML and articulate architecture, but don’t make it a fetish… be prepared to read and understand, but don’t spend your days creating UML diagrams. This is the path to the dark side, which leads to irrelevancy.
Defines Technology Stack
Some could argue that this is the realm of designers. There is definitely a gray area between architecture and design. Each team and organization seems to delineate this distinction differently. Often, software is developed without a design team or a designer, however most corporate software teams consist at a minimum of the architects and the developers. The architect defines the libraries, technology stack and protocols. For aspiring architects, you need to have experience with a large number of technology options, this doesn’t mean you read about it and you think you know… it means you have applied it, and you understand it. Obviously this could be a huge time sink. The alternative is to network and associate with other skilled architects. Attend conferences… read blogs and books… increase your knowledge portfolio.
Although the network architect usually defines the network infrastructure, clearly it is part of the overall system architecture. It is required of a good software architect to have a general to good understanding of system networking (beyond that of a normal developer), which includes the understanding of IP address schemes, network latency, subnets, the difference between TCP and UDP, understanding of a trace route and can read a network diagram. This is the foundation of the system topology. Many software systems do not require this level of knowledge, but many distributed web systems do.
Outside of the project manager, the architect has a large amount of influence on the project methodology. It is useful to know and understand the difference between waterfall and iterative development. In the iterative methodologies it is important to understand the difference between Agile and RUP. Critical to the success of a project is early and often feedback from the user. This is the most significant advantage of an iterative process. It is important to understand that Agile is usually a feature slip model, where dates are adhered to and the lowest priority features slip. RUP is a time slip model, where the team works on the highest risk, most complex use case(s) and the iteration doesn’t end until it is done. This provides an early indication of how accurate the estimates are and early knowledge if the project will likely be late. The role of the architect is not usually associated with the development methodology for most formally defined methodologies, however it has been my experience that the architects often provide guidance to and recommend changes for the development process.
The architect can be one of the most influential members of the team. In order to have leadership you have to have two things… 1) technical depth, be the go-to person and 2) moral fortitude. If you have high morals without technical depth, you are considered a nice person. If you have technical depth and no morals then no one can trust you. It requires both.
The common methods of motivation are the carrot (reward) and the stick (creates fear). One of the largest issues I see with new leaders is a desire to “enforce” their decisions. Resist the urge. Lead!
As part of the role of leadership, you will need to make decisions for which there is more than one way to accomplish the end goal. Or it is “perceived” by other members of the team that there is another way, or a better way, or… Like many leadership positions, often you will need to make a decision in the absence of information. It is easy when the decision isn’t yours, when you are playing armchair quarterback. As an architect it will be your decision. As soon as you make a decision, it will be challenged. You will need to have the fortitude to withstand the buffeting of these challenges.
Mentoring and Coaching
As a technical leader and a senior member of the team, the architect is asked or requested to be the mentor for other team members. This includes career path advice, code and design reviews and etc. Regardless whether you asked for it, or like it, you are the example for the development team.
It is important for the architect to be in the game. As the architect you have to be exposed to the consequences of the architectural decisions. Which means you have to be coding… don’t lose touch with the code!! As a quarterback, you are not often running the ball in for the touchdown, but you are in the game. If you stop coding, you are useful as an architect (depends on complexity of the system) for six months to two years.
The architect often plays the role of the tool smith, or influences the need for the tools smith regarding source control, build process, continuous integration and testing. Certainly in large organizations many of these aspects and roles are divided up into a number individual roles. Even if this is the case, most of the time the direction for these activities comes from the architect or architecture team.
The architect is usually the most influential member of the team as a change catalyst. This includes changes to the development process, version control process, team structure, etc. This will require not only an understanding of the development processes, but also where the deficiencies are on your team. In the end the architect is responsible for the integrity of the system. This means (s)he must be able to have early detection to anything which threatens that integrity and is responsible for influencing changes to ensure that integrity.
One of the 7 habits of highly effective people is to begin with the end in mind. The ‘end in mind,’ or vision, is the combination of the requirements and the “vision” of the architect. It is very important that the architect share a crystal clear vision of what the system looks like to the team. A word of caution… do not let vision mean that you are going to future proof your system. That you are going to build a system that will withstand the next 10 years with nothing more than a configuration change. This has been the downfall of many systems.
The architect translates user or business analyst requirements into technical requirements. The architect also translates technical capabilities to the business or user. This requires the architect to be fluent in the language of the business as well as strong in the ways of the developer. Too often development teams say no to business. It is a significant problem in our industry. Rarely if ever is the answer of feasibility “no”. The answer is “under these constraints it can not be done. If you as the business can remove one of these constraints then it may be possible.” The architect needs to empower the business and users with the information to make the right decision.
Practices and Standards
The architect defines for a project or department the coding standards and guidelines. This includes standards for system protocols and can include the micro details such as beautification rules (braces on the same line or next, number of tabs, etc.), or macro details such as the web application will be request centric, leveraging a MVC model using a stateless service model. Again a word of caution… this leads, for many organizations, to a center of excellence (COE) and “best practices”. The value for the COE and best practices varies for many corporations and can lead to less innovation, stagnation of development and general frustration for developers. As Ted Neward once said, “All Dogma is evil… even this sentence”. Make sure you know what you want from an architectural committee. You often get standardization but you generally do not see innovation come from architecture committees. It is more likely you will get things such as EJB 1.0 or 2.x, which was created by the JCP. There can be value in standardizing aspects of a software system. Just make sure you left room to innovate as well.
Unfortunately it will be necessary to deal with politics and to be a politician. This is true regardless whether you are compromising on aspects of the system with developers, negotiating with the business or debating with other architects in the center of excellence… I mean the jedi council… I mean the architecture steering committee. Being able to articulate needs in a socially acceptable way is vital to corporate success.
In addition to all previously mentioned roles, it is expected that your technical-fu is strong. This includes:
- Understanding of database schemas, indexes, etc.
- Strong with development principles
- Coupling and Cohesion
- Strong vs. Weak Typing
- Dynamic vs. Statically Typed Languages
- Imperative, Functional, object-oriented, procedural
- XML Schemas, XML Transformation and Canonical Models
- REST, SOAP, and Web Services
- EAI Patterns
It is important to be able to abstract the benefits from a toolset and then leverage that experience for other toolsets. For instance, there are substantial similarities between DCOM, CORBA, RMI and SOAP. At the implementation level these distributed frameworks are very different, there are many similarities at the macro or meta level. This ability to compare and contrast patterns and benefits, as well as visualizing patterns up and down levels of abstraction is vital as an architect.
While it is not clear if a definition of architect exists that we can all agree on, it is clear that architects are vital members of a software development effort. Although a large number of roles are defined in this article… and perhaps I missed some, the goal of the role of Architect is system integrity. This integrity is accomplished through the balance of user requirements, non-functional requirements and team, company and system constraints.
About the Author
Ken has worked with Fortune 500 companies to small startups in the roles of developer, designer, application architect and enterprise architect. Ken’s current focus is on enterprise system automation and continuous delivery systems.
Ken was the founder of CodeMentor, where he was the Chief Architect and Mentor, leading clients in the execution of RUP and Agile methodologies in the delivery of software solutions. He is a former trainer for Rational in OOAD and RUP, and a CORBA Visibroker trainer for Borland. He continues to enjoy providing training and mentoring in all aspects of software development. Ken has a deep need to be highly diversified. Ken often works with IT executives on high-level strategic roadmaps, currently geared around service oriented architectures (SOA). Ken also likes to keep his hands “dirty” in the code, which has him on a regular basis, pairing or otherwise producing code. Ken is regularly requested by clients that know him to “rescue” projects, either through the streamlining of processes or the rapid production of code.
This article was originally released in NFJS The Magazine.