Hi Joel, an interesting question! I tend to initially approach this from a couple of different angles, focussing on why software architecture is important (e.g. looking at maintainability, security, performance, etc) and what they perceive the role of a software architect to be. If you do enough listening and exploring, you'll often bring out the horror stories of projects gone wrong. This then provides a basis to explain how some "architecture time" could have helped prevent some of the issues.
Joel Neely wrote:Given that architecture doesn't directly tie to tangible, user-visible features
I have a hard time accepting this premise. Architecture is about form and function. If a building's form does not support its function, then surely the occupant will notice it. Same thing goes with software. Let's go back to everyone's favorite whipping boy these days: the much maligned (and justifiably so) healthcare.gov website. One of the first things that jumped to my mind when I first heard about the problems plaguing that website was poor architecture. Sure, poor implementation too but I think the lack of functionality and poor performance tie directly back to poor architecture.
Conway's Law states that the structure of a software system reflects the structure of the organization that developed it. Can you imagine the mess that results from 50+ contractor companies trying to come up with a complex system that needs to cater to millions of users and interface with a number of government agencies and private companies? And have that system working in such a relatively short amount of time? I have worked on government IT projects before and I think it's a small miracle that they even got it off the ground when they did.
The section about Quality Attributes in #sa4d alone will give you and your stakeholders plenty to talk about that can be tied directly to architecture.
TOGAF addresses this subject very nicely. TOGAF has the concept of views and viewpoints. Viewpoints represent the concerns of the stakeholders, and differrent stakeholders will have differrent view points. So, let's say you are building a banking application for a brick&mortar bank who is trying to provide online features for their existing customers. You might have bank managers who are very concerned about how easy the application will be for their customers to use. The IT engineers will be concerned about how the application will be deployed and monitored. And the CEO might be concerned about the security of the application(He wants to make customers happy, but he would prefer to have slightly unhappy customers if it meant that he will not lose all their money: D) . You have 3 differrent people who are looking at the same thing but in 3 differrent ways. So, as an architect you build views that addresses those viewpoints. You might produce UX wireframes for the bank managers, deployment diagrams for the IT engineers, and a description of the security mechanisms for the CEO. Of course, you need to make sure the architect addresses those concerns, so you need to create the artifacts that show the developers how the application will address those concerns. So, for the devs you create design docs that have solutions for all the concerns "baked into" the design.
sharp shooter, and author
Joined: May 10, 2000
Jayesh is right, it's all about expressing the architecture in different ways for different people. Out of interest, how many teams do you see using TOGAF? It's not something that I see much of, except in very large organisations. But then, to be fair, I don't really engage with enterprise architecture teams...
I haven't seen anyone say they use TOGAF, but I've been TOGAFish since I dunno when. I learnt TOGAF because I had been an architect for about 4 years now, and I was looking for a job, and I wanted some certification on my resume. Also, I wanted to get an idea of what other people mean when they say "architect" outside my company.
While studying TOGAF, I figured out that a lot of people use TOGAF in principle. TOGAF borrows a lot from a lot of good practices that people already follow. IOW, TOGAF is basically codification of industry wide architecture principles. So, a lot of people have been TOGAFian in principle, but probably not TOGAFian in the detail. So, if you ask me "do you know what kind of diagram to draw that addresses which features should be built first?" I will say "Umm.. maybe Value Chain diagram.. let me look it up in the book at get back to you". However, conceptually, (or as TOGAFians like to say, in the architecture continuum), I've been following TOGAF, since even before I was an architect. I have drawn diagrams to address specific concerns for specific stakeholders. Have I stuck to to the diagrams that TOGAF reccomends? No
Simon, you might want to look at TOGAF, if you haven't. I haven't read the whole book, but looking at your sample chapters, you might be a TOGAFian at heart. It has it's roots in big enterprise architecture, and parts of it is designed to enable "relay style development". However, the current version of TOGAF is more agile and iterative, and also addresses some of the things that you say. For example, previous versions of TOGAF simply prescribed what kidn of artifacts the EA should create, whereas the current one talks about adding a governance phase that drives you next iteration of architecture work. Which is basically TOGAFian-speak for "make sure the developers are sticking to your architecture, and if they are not figure out why and change your architecture accordingly"