Are You a Software Architect?
- Share
-
- |
Read later
My Reading List
Editors note: The author of this article, Simon Brown, will be presenting a tutorial at QCon London coming up this March on the same subject of this article, entitled Software Architecture for Developers.
The line between software development and software architecture is a tricky one. Some people will tell you that it doesn't exist and that architecture is simply an extension of the design process undertaken by developers. Others will make out it's a massive gaping chasm that can only be crossed by lofty developers who believe you must always abstract your abstractions and not get bogged down by those pesky implementation details. As always, there's a pragmatic balance somewhere in the middle, but it does raise the interesting question of how you move from one to the other.
Some of the key factors that are often used to differentiate software architecture from software design and development include an increase in scale, an increase in the level of abstraction and an increase in the significance of making the right design decisions. Software architecture is all about having a holistic view and seeing the bigger picture to understand how the software system works as a whole. While this may help to differentiate software development and software architecture, it doesn't necessarily help to understand how somebody moves from development into architecture. Furthermore, it also doesn't help in identifying who will make a good software architect, how you go about finding them if you're hiring and whether you are a software architect.
Experience is a good gauge but you need to look deeper
Becoming a software architect isn't something that simply happens overnight or with a promotion. It's a role, not a rank. It's an evolutionary process where you'll gradually gain the experience and confidence that you need to undertake the role.
There are a number of different qualities that you can look for in a software architect and their past experience is often a good gauge of their ability to undertake the role. Since the role of a software architect is varied though, you need to look deeper to understand the level of involvement, influence, leadership and responsibility that has been demonstrated across a number of different areas. Broadly speaking, the software architecture on most projects can be broken down into two phases; the architecture is defined and then it's delivered.
Definition of the software architecture
The architecture definition process seems fairly straightforward. All you have to do is figure out what the requirements are and design a system that satisfies them. But in reality it's not that simple and the software architecture role can vary wildly depending on how engaged you are and how seriously you view your role. As the following diagram shows, the architecture definition part of the role can be broken down further into a number of different elements.
- Management of non-functional requirements: Software projects often get caught up on asking users what features they want, but rarely ask them what non-functional requirements (or system qualities) they need. Sometimes the stakeholders will tell us that "the system must be fast", but that's far too subjective. Non-functional requirements need to be specific, measurable, achievable and testable if we are going to satisfy them. Most of the non-functional requirements are technical in nature and often have a huge influence on the software architecture. Understanding the non-functional requirements is a crucial part of the role, but there's a difference between assuming what those requirements are and challenging them. After all, how many systems have you seen that genuinely need to be operational 24x7?
- Architecture definition: With the non-functional requirements captured, the next step is to start thinking about how you're going to solve the problems set out by the stakeholders and define the architecture. It's fair to say that every software system has an architecture, but not every software system has a defined architecture. And that's really the point here. The architecture definition process lets you think about how you're going to take the requirements along with any imposed constraints and solve the problem. Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project. Defining architecture is your job as a software architect but there's a big difference between designing a software system from scratch and extending an existing one.
- Technology selection: Technology selection is typically a fun exercise but it does have its fair set of challenges when you look at cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments and so on. The sum of these factors can often make a simple task of choosing something like a rich client technology into a complete nightmare. And then there's the question of whether the technologies actually work. Technology selection is all about managing risk; reducing risk where there is high complexity or uncertainty and introducing risk where there are benefits to be had. Technology decisions need to be made by taking all factors into account, and all technology decisions need to be reviewed and evaluated. This includes the major building blocks for a software project right down to the libraries and frameworks being introduced during the development. If you're defining an architecture, you also need to be confident that the technology choices being made are the right choices. Again there's a big difference between evaluating technology for a new system versus adding technology into an existing system.
- Architecture evaluation: If you're designing software, you need to ask yourself whether your architecture will work. For me, an architecture works if it satisfies the non-functional requirements, provides the necessary foundation for the rest of the code and provides a sufficient platform for solving the underlying business problem. One of the biggest problems with software is that it's complex and abstract, which makes it hard to visualise the runtime characteristics from UML diagrams or the code itself. We undertake a number of different types of testing throughout the software development lifecycle to give us confidence that the system we are delivering will work when rolled out. So why don't we do the same for our architectures? If you can test your architecture, then you can prove that it works. And if you can do this as early as possible, you can reduce the overall risk of project failure rather than simply hoping for the best.
- Architecture collaboration: It's unusual for any software system to live in isolation and there are a number of people that need to understand it. This ranges from the immediate development team who need to understand and buy in to the architecture, right through to other stakeholders who have an interest from a security, database, operations, maintenance, support, etc point of view. For a software project to be successful, you need to collaborate closely with all of the system stakeholders to ensure that the architecture will successfully integrate with its environment. Unfortunately, architecture collaboration within the development team seldom happens, let alone the external stakeholders.
Delivery of the software architecture
It's the same story with architecture delivery too, where the software architecture role can vary depending on the level of engagement across the elements that contribute to a successful software project.
- Ownership of the bigger picture: In order to carry the architecture through to a successful conclusion, it's important that somebody owns the big picture and sells the vision throughout the entirety of the software development lifecycle, evolving it throughout the project if necessary and taking responsibility for ensuring that it's delivered successfully. If you've defined an architecture, it makes sense to remain continually engaged and evolve your architecture rather than choosing to hand it off to an "implementation team".
- Leadership: Owning the bigger picture is one aspect of technical leadership, but there are other things that need to be done during the delivery phase of a software project. These include taking responsibility, providing technical guidance, making technical decisions and having the authority to make those decisions. As the architect, you need to undertake the technical leadership to ensure everything is taken care of and that the team is being steered in the right direction on a continuous basis. The software architect position is inherently about leadership and while this sounds obvious, many project teams don't get the technical leadership that they need, with architects assuming that a successful delivery isn't necessarily their problem.
- Coaching and mentoring: Coaching and mentoring is an overlooked activity on most software development projects, with many team members not getting the support that they need. While technical leadership is about steering the project as a whole, there are times when individuals need assistance. In addition to this, coaching and mentoring provides a way to enhance people's skills and to help them improve their own careers. This is something that should fall squarely within the remit of the software architect, and clearly there's a big difference between coaching your team in architecture and design versus helping them with their coding problems.
- Quality assurance: Even with the best architecture and leadership in the world, poor delivery can cause an otherwise successful project to fail. Quality assurance is a large part of an architect's role, but it's more than just doing code reviews. For example, you need a baseline to assure against, and this means the introduction of standards and working practices. From a software development perspective, these could include coding standards, design principles and source code analysis tools through to the use of continuous integration, automated unit testing and code coverage tools. It's safe to say that most projects don't do enough quality assurance, and therefore you need to figure out what's important and make sure that it's sufficiently assured. For me, the important parts of a project are anything that is architecturally significant, business critical, complex or highly visible. You just need to be pragmatic and realise that you can't necessarily assure everything, doing something rather than doing nothing.
- Design, development and testing: The last thing that falls squarely within the role of a software architect is design, development and testing. Being a hands-on architect doesn't necessarily mean that you have to get involved in the day-to-day coding tasks, but it does mean that you're continuously engaged in the project, actively helping to shape and deliver it. Having said that, why shouldn't the day-to-day coding activities be a part of an architect's role? Most architects are experienced coders, so it makes sense to keep those skills up-to-date. In addition, the architect can experience the same pain as everybody else on the team, which in turn helps them better understand how their architecture is viewed from a development perspective. Many companies have policies that prevent software architects from engaging in coding activities because their architects are "too valuable to undertake that commodity work". Clearly this is the wrong attitude ... why let your architects put all that effort into defining the architecture if you're not going to let them contribute to its successful delivery? Of course, there are situations where it's not practical to get involved at the code level. For example, a large project generally means a bigger "big picture" to take care of and there may be times when you just don't have the time. But generally speaking, an architect that codes is more effective and happier than an architect that watches from the sidelines.
Are you a software architect?
Regardless of whether you view the line between software development and architecture as mythical or a gaping chasm, the elements above highlight that people's level of experience across the software architecture role varies considerably depending on how engaged they are and how seriously they view their role. Most developers don't wake up on a Monday morning and declare themselves to be a software architect. I certainly didn't and my route into software architecture was very much an evolutionary process. Having said that though, there's a high probability that those same developers are already undertaking parts of the software architecture role, irrespective of their job title.
There's a big difference between contributing to the architecture of a software system and being responsible for defining it yourself; with a continuum of skills, knowledge and experience needed across the different areas that make up the software architecture role. Crossing the line between software developer and software architect is up to you, but understanding your own level of experience is the first part of the journey.
About the Author
Depending on your viewpoint, Simon Brown is either a software architect who codes or a software developer who understands architecture. When he's not developing software with .NET or Java, Simon can usually be found consulting, coaching or training. Simon has also written books about Java, presented at industry events and has put together a training course called Software Architecture for Developers, which is based upon his software architecture writing at Coding the Architecture. You can catch up with Simon by e-mail or Twitter.
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
You just need to be pragmatic and realise that you can't necessarily.
by
Paulo R. A. Sales
First all congratulations!
I like your view about a software architect which can code with team to keep their skills and feel how your architecture is hard or easy to implement. I think that is realy necessary a software architect act this form.
Thank
Good Article
by
Alexandre Poitras
Love the emphasis on Ownership, Collaboration, Leadership
by
Tim Morrow
Great. Remember Architecture is the final product
by
William Martinez
I would remark that Architecture is not the design, but the working structure after the coding is complete. That is, the architect should not end his job without seen the creature crawling.
The architecture description and definition is all that you say.
Architect is a part of the team, not superior, and may not be expert on the language at hand, but should be involved in coding. And coding does not mean writing ifs and classes, but actually deciding on strategic, tactical and operational issues.
Cheers!
William Martinez Pomares.
Architect's Thoughts Blogger Twitter
Quite in Line
by
Vikas Hazrati
Is it really that simple?
by
Gary Shepard
When it comes to the title of "Architect" there must be a distinction as what type of architect do you need!
Integration Architecture?
by
Hamdi Yusof
One question please.
What about integration architecture which integrates dozens of systems (java, .net, .net mobile running in scanners, vb6, sap, etc) fairly seamlessly. Are these the work of a software architect?
Thanks.
What about functional requirements?
by
Johannes Brodwall
Interesting article
by
Thanh-Liem Tran
In my point of view, a good architecture design must be extensible and must also be able to fit into an existing system. The architecture solution proposed must response to the needs of the client (which are most of the time funky), and respect the non-functional aspect of the application without impacting the scalability and the quality of the whole system (non-regression).
Choosing the technology is also, an important aspect of the role played by the architect. In most of the time, people will goes with the technology they knows best, others will go with "extreme" technology, which are most of the time hard to find resources to maintain this techno. Having a compromise, to choose a technology that can be use is another debate. But the number of different technologies used within a company are most of the time limit, and it is normal.
In conclusion, the architect role, is not as simple as it appear.
cheers.
Good article. Clear and concise
by
Juan Jose Zapico
Cheers.
It's all about the Abstractions, baby
by
Dave Marney
Here's my pick for what sets architects apart:
<ol>
A pretty hard set of skills to find in one person.
Re: Is it really that simple?
by
Hamza BENMANSOUR
It's really about a bigger picture
by
Shirley Z
Re: Integration Architecture?
by
Paul Nita
SCEA
by
roberto parra
scale
by
Humphrey Bogart
Re: It's all about the Abstractions, baby
by
Simon Brown
I agree, indeed they are and I think your additional list of skills can also be applied to any good senior people, non-technical roles included. I alluded to this at the end of the article, but there are lots of senior people out there that are already doing what we've both described and aren't recognised for it. On the other hand, there are lots of people out there with "architect" in their job title that don't necessarily have those qualities.
> A pretty hard set of skills to find in one person.
It is, and I've seen people that haven't been recognised in the past because they've not "ticked all of the boxes". My view of the software architect role came about from interviewing people and trying to ascertain what level of experience and engagement they *really* had on their projects. It turned a "box ticking" exercise into a discussion, which I found really useful in helping to identify whether they were a software architect.
Re: Good Article
by
Simon Brown
You're right, and it would be great if organisations used something like the model I described when reviewing their software architects rather than the cursory, "yes, you seem to have done a good job". Perhaps teams should implement the same agile feedback mechanism that the QCon organisers do ... at the end of every iteration/release everybody votes with a green, yellow or red card for each team member. Get too many red cards and you're out! :-)
Re: Great. Remember Architecture is the final product
by
Simon Brown
> I would remark that Architecture is not the design, but the working structure after the coding is complete. That is, the architect should not end his job without seen the creature crawling.
I agree and having a "working" structure is why it's crucial for software architects to be involved in defining it and delivering (building and using) it. "Working", for me, means delivering the right foundations to provide business value and seeing the creature crawl (preferably as early as possible).
> Architect is a part of the team, not superior
That's an interesting point ... software architecture is really just a different role played out on a software team. To be honest, it doesn't need to be allocated to a single person and I'd be really happy to see a team where everybody is collaborating on the architectural aspects of the software. Unfortunately it's more common to see teams where nobody is thinking about it, and that's when you get systems that don't perform/scale/fit into the operational environment/etc. We'll build better software as an industry if everybody better understands the "bigger picture" stuff.
Re: What about functional requirements?
by
Simon Brown
Re: It's all about the Abstractions, baby
by
Rainer Eschen
blog.rainer.eschen.name/2008/02/20/the-mission-...
Re: Integration Architecture?
by
massyl nait
Thanks for these precisions and definition of software architect, because lots of people need to update their definition of this role. I totally agree with you about hands-on architect, i believe that is, one point that must be taken seriously if we want to get a successful solution.
I want to add that collegial works to define some architecture solutions (even though perhaps there is one or little people that will make the decision in the end) is also a big thing to take into account, because we need different point of view before getting the right solution some times, (two heads are better than one).
Good experiences obviously help to be good architect, but I don’t think that is the only characteristic that defines it, I’ve encountered very experienced people playing the architect’s role that are out and understand nothing to architecture.
I will close my comment by saying that software architect needs to rely on abstraction, abstraction … but also remain closer to implementation in order to avoid gas plant software.
Cheers
Good Article
by
massyl nait
apologize
Re: What about functional requirements?
by
Johannes Brodwall
Relationship building
by
Kevin Webber
Re: Great. Remember Architecture is the final product
by
Paul Beckford
Great article. Despite being an XP zealot :), I agree with you that some architecture is better then none, and if having a dedicated role of "Architect" is the only way to get architecture on the agenda then I agree its a necessary evil in that environment :) Like you, though I think this necessity points to a deeper problem, and the ideal solution is if everyone got involved in understanding "the bigger picture".
I like the way you've broadened the definition of the role. Like others have mentioned you've mostly focused on Application Architecture. There is the whole area of Enterprise Application Integration (EAI) to consider also.
There you get into the notion of a separate enterprise technology strategy team, and that's when the real fun starts :)
There is scope here for another article I think :)
My two cents is that architecture at all levels should be an emergent property, driven by the requirements of the end customer(s). For this to happen, the people making the decisions need to be intimately involved with customers and their applications. This translates in to application teams collaborating and making decisions bottom up. No ivory towers :)
Paul.
false dichotomy
by
Gene De Lisa
Any other title is mental masturbation.
Ability to detach from implementation details marks an architect
by
Dan Mason
Also, the question of whether architects are "portable" is recurrent. If an architect is a great coder in C# and knows the .NET stack inside out, can they still architect in a J2EE, without becoming expert? I think so. Maybe this is not a great comparison since java and C# are so similar, but hopefully you get the point of the question: is an architect's value dependent on his/her knowledge of the specific implementation technologies?
functional design needs equal attention
by
Shrikant Khupat
Share the same views; I believe in having equal focus on functional design as well.
Because there are many reference architectures available which are proven.
But I see the functional design area still needs architects attention;
I have seen many GOOD architectures failing just because the functional design is adhoc..
Cheers!!!
Shrikant
Constant change
by
Doug Edmondson
Educational Content
Concurrency in Clojure
Stuart Halloway May 17, 2013
Confessions of an Agile Addict
Ole Friis Østergaard May 16, 2013
Web Development: You're Doing It Wrong
Stefan Tilkov May 16, 2013
Programming The Feynman Way
Ben Evans May 15, 2013
Infoq Weekly Newsletter
Subscribe to our Weekly email newsletter to follow all new content on InfoQ
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think