William Martinez has pointed me to a paper which talks about Emergent Design from an Architects perspective. Apparently Architects are now deferring architectural decisions to the last responsible moment in an attempt to be more Agile.
On the same site they present a skills matrix defining the role of an architect. looking at the matrix it looks as though the new Agile Architect is a cross between a Systems Design Engineer a Senior Development Lead and an Agile Coach.
To me the term Agile Architect is a misnomer. Architecture as I understand it is about technology selection high level design. In an Agile team, the team are responsible for making such decisions. If the Architect is part and parcel of the team or is an outside consultant that the team can consult then I guess that this approach is still consistent with say Scrum. But ultimately the team must decide. Since the team is ultimately responsible for delivery. Anything else would brake the central tenant of Scrum which is that the team should be self organised and make their own decisions.
It puts me in mind of Scott Amblers website on Agile Modeling. Again a central tenant of Agile Development is feedback. Yet you don't get much feedback from a non-executable UML Model until pretty late in the development process. So again Agile Modeling is a bit of a misnomer.
So why are we seeing such things? Well in my opinion this is the consequence of organisations that have structured themselves around a waterfall "production line" view of software development who never the less like the sound of Agility, yet do not want to confront the need for organisational change. To me these are just symptoms of Agile as a fad. Wannabes jumping on to the bandwagon. Me too Agile.
True Agile seems to be taking root in environments with less cultural baggage such as new startups. But for those who are merely interested in trying out the latest fad without making a real commitment to cultural change, they can change their practices a tad and re-brand themselves as Agile. "Me too" Agile. Which is what I believe we are seeing here.
13 comments:
Paul, interesting you mention this subject, I noticed the 'agile modeling' stuff some time back and at the time, it just didn't quite ring true. I thought nothing more of it and moved on. Guess it really comes down to 'do the right thing', but to me, all there is to this subject is a few guys getting together in front of a white board and 'modeling something' on an as needed basis. There's nothing more to it than that. Modeling is simply a way of sharing understanding amongst the team.
Architecture is an interesting subject. What is architecture? To me, its simply high level design decisions, which happen to describe key mechanisms in your product. This activity absolutely needs to be within the development team - however, there is a need to be able to share information of what the architecture is and how to take advantage of the hard work other teams have already done. This problem at its simplest can be solved by the somewhat contentious idea of actually talking to people. If needed, the shared information can be documented - yes this can be an agile activity. The worst form of architecture however is the boxologist (aka Visio jockey) with some authority. These animals frequently 'dictate' architecture without actually taking responsibility (they tend not to be hands-on). A final word on this subject - architecture is word play. Good developers are architecting all the time, on many levels of abstraction, its just not formally recognized as such.
So, talking of documenting stuff, I really liked Mary Poppendieck's post on infoq about Leadership recently. She described Taiichi Ohno's (viewed as the father of the Toyota Production System) viewpoint on documents, which is that they are a starting point from which one must improve. If you view standards as best practice - its all over - you just don't get it. Her words are very powerful.
Yes I agree Andy. Architecturing is just word play. It is noting more than design.
I agree about your point on responsibility too. Those who make the design decisions should also be on the hook to deliver.
About communication. Firstly you need to identify an audience and a purpose. Much that goes under the banner of architectural documents identify neither.
When the audience is developers what is wrong with code as a communication medium? And I agree that the best form of communication is face-to-face perhaps in front of a white board.
You raise a very good point about standards. The "production line" organisations I speak of have "best practices" that are fixed. True standards are meant to change in light of experience. If premature design decisions are not helping you you need to change your standards so that documents defining design decisions up front are no longer compulsory.
It comes down to ticks in boxes and conformance.
Last point. The visio jockey mentality really has a high price. I believe it has coloured our whole approach to engineering software systems. A number of standard architectural design patterns have caused us to get locked into ideas that bare no relation to the problems we meant to be solving.
Take a look at my previous post on N-tier architectures for instance. I would be interested in your comment.
BTW. this elaborate modeling obsessed attitude as also permeated our programming languages too. I reference a blog by Steve Yegge where he discusses the effect of over elaborate code, and programming languages that restrict access to the computational model.
Interesting stuff.
I agree with your point about a lot of organisations taking a "me too" approach to agile development and it's very obvious that most of them don't understand what they are getting into.
As far as architecture goes, that role profile/skills matrix is intended to show the sort of things that we think an architect should do and be responsible for. It doesn't define what an "agile architect" should do.
While "agile architecture" might be a misnomer, personally, I think that agile projects need to adopt more architecture than they typically do and that traditional projects need to do less architecture than they typically do (well, maybe do less up front).
Rather than saying "agile architecture", I'd say that I'm keen on a "just enough" view of architecture. Architecture is important and there are some decisions that cannot be deferred to later in the project. My view is that I want to see working code as early as possible, but I want that code to de-risk the complex architectural decisions.
I'll try to track down whether the video was recorded for that session, but the important statements are on the last page :
It’s not just the code that wants to know what the architecture is so “the last responsible moment” may well be sooner than you think.
Don’t hide behind the methodology or lack of pressure – do your job and define the architecture :
- Spike
- Prototype
- Proof of concept
Simon Brown, Coding the Architecture
Hi Simon,
I liked your Summary:
- Spike
- Prototype
- Proof of concept
A lot of this does need to be done up front I agree. Balance in all things.
My concern is how to keep the Architect accountable. If the spike/prototype/proof of concept phase is executed poorly then it is the performance of the development team that is impacted.
Feedback is not just a technical issue. Feedback on people and their performance is important too. With Scrum the team is responsible and accountable for their decisions. The burndown chart provides visibility on how well they are doing.
My personal view is that collective responsibility is best. So the team (including the Architect) should be responsible for Architecture/design.
If we take the root that the architect is the architectural authority, then we need the same level of visibility for the quality of work delivered by Architects.
Any ideas?
> My concern is how to keep the Architect accountable. If the spike/prototype/proof of concept phase is executed poorly then it is the performance of the development team that is impacted.
This is one of the reasons that I believe it's important for architects to remain on the project team. If the spike/etc is executed poorly, then the architect still remains accountable. I think it's unfair to place fault on the development team in situations like this. Somebody has to take accountability, and that's the architect.
Hi Simon,
We agree and this approach is totally consistent with Scrum. In fact I believe that Scrum goes as far as saying that experts in specific areas can be part time resources on the team. The main point is control and accountability. If the Architect does a poor spike, then the team can choose to reject his recommendations. The architect is subject to peer review, just like any other member of the team. Of course some one needs to have a final say if the team can't reach a consensus, but I would make that person the team lead.
I agree with Andrew that Architecture is technology selection and high level design. Technology selection can be a specialism I agree, but in practice I am not sure this is solely how Architects are used.
What I see is high level design and technology selection decisions being imposed on teams top-down. Usually the architects are in cahoots with the strategy team who in turn are in cahoots with the strategic technology partner. I'm sure you've seen this.
Now Scrum teams are accountable to the customer who is the owner of the product. Customers and teams can collaborate on a strategic level, harvesting good designs and good technology choices across the organisation. In Scrum this can occur at a Scrum of Scrums where Scrum masters from different projects get together and share ideas on a regular basis.
I even see a role for a Strategy team or an Architecture team, who could go off an evaluate technologies and strategies at the bequest of customer/development teams.
This would ensure that strategic control is in the hands of the customers/business units, and not some self serving ivory tower. Just an idea.
The part of your paper that concerned me is this sentence:
"But the decisions still need to be made from a position of technical authority - otherwise what is the point in architecting?"
Can you expand. I would assume that the team was is in a position of technical authority, not just the architect. If the team can't be trusted with technical decisions, then perhaps you need to change the team.
Thinking a little further on this, it gets more interesting. Simon, what is architecture? Do you view architecture as something that not everyone can or should do? Why?
I used to think very much in terms of pigeon-holed roles, every team needs a BA, QA, Architect, PM etc. When it all boils down however, this belief actually confirms what the Japanese and more enlightened societies know about western values - we don't want to trust people, we still want someone to tell the 'workers' what to do. To me, this still conforms to the Taylorist school of thinking. We still love to feed the ego. Many still can't wait to proclaim 'I'm an architect' or a Business Analyst, rather than grow their capabilities as a developer - why? Ego, control, the feel-good factor.
If your team flounders, and you feel need to command and control then there are several possibilities - you haven't hired good developers or they don't feel empowered and perhaps need coaching.
The good teams I have worked with 'get it' and have an understanding of how to work with customers and deliver a product. Business analysts and architects generally do not.
Having said all that - I have a case right now where someone who works on one of my teams is a very strong developer - and understands how to build systems, but because of ignorance, organizations do not allow the progression of strong individuals and they have to be 'promoted' into architect type positions. This also helps them to feel empowered (in a fear-based environment, more prevalent in the US than in Europe) - to make change. This however is more a consequence of western society and unhealthy organizational norms.
Yes, we will have various members of the team that all have differing degrees of talent and skills. Put trust in your team and the most talented and experienced will emerge as leaders.
Me Too Agile.
Ok, Agile is the thing that values:
-Individuals and interactions over processes and tools
-Working software over comprehensive documentation
-Customer collaboration over contract negotiation
-Responding to change over following a plan
Apparently? No, I don’t know why they title Agile whatever, more than being just a buzzword compliant. Agile is a buzzword, the important thing are the ideas above.
There is no “new Agile Architect”. The Matrix is one particular role definition. Eoin Woods has his own role definition; same as Bredermeyer that defines them by competences. I do have my own. And all of them have nothing to do with Agile, but with the work an architect has to do. I personally don’t care about the agile title, Agile people do.
Wrong again, Architecture (the process) is not about technology selection. That is fraction the architect “helps” to do (yes, it is a team work).
Amblers falls into the same misconception you do: Modeling is not, by nature, incompatible with the four principles above. Modeling is not paper generation, everybody must understand that. Modeling is a description methodology to solve the problem, not to document comprehensively.
Andrew, you say good about modeling as a tool to share understanding. But it is a little more than that. Good point too about architecture as high level decisions, but it is far more that only that. About developers architecting: True! At all levels. The architect should be the guide (to do that, he/she must know how to do it, and needs all the competences in the matrix, not just being good programmer). Documents, they are not a point to start, they are just a medium: the point to start is the concept they describe, which must evolve.
Architecturing is not word play, sorry. But I grant you may not actually see what I do everyday, so I guess you are taking some guys as models. We need to change that. I mean what the guys with architect’s hats are doing and your view.
When in a project, everybody has responsibilities, and when the project fails the team receives the blame. Before, the Project Manager was not part of the team, now it is. Architects were not even in the company, now they are, involved in all the projects, part of the team. There is no Ivory tower. But no everybody does the same: each one knows what his/her role is, and there are some tasks that are not only coding.
Audience: What? One of the first things to do is to identify the stakeholders. Architect needs to make them commit to the system, and hear all what they need to say. Stakeholders go from the user to the company lawyer, from the paying guy to the developer, from the testing team to the operations team (Woods identifies 10 stakeholder types, not all of them developers). The decisions taken must be understood by all, and approved too. If developers think the decision is not good, a discussion of why is a must. If the lawyer does not think the solution is politic compliant, then we need to see why. So, Code is not the only communication media, it can’t be. I told you, in a software intensive system solution, there is more than just the developer and the machine.
Standards are to be followed, then evolve. A best practice should be there because is good, if it is not working it must be changed. A best practice should say: use the appropriate technology, not say: use the XX vendor.
Good one about vision. Extreme obsession is bad. Coding, diagramming, modeling, talking, writing blogs…. But that last one is not so bad.
Simon:
All good points. Only that we don’t do “less architecture”. We need to do full architecturing process, always! Architecturing is not diagramming or delaying the start of coding until I see the last if in my mind. Architecturing is talking to people, gathering information, discussing, deciding, coaching, supervising, updating info… there is no such thinkg as time for architecture and then a time for coding, all is happening at the same time, and we have no time to breath. If an architect spends all his time making diagrams and documents, he is a documenter. Believe me, I hardly have time to document!
Back to Paul.
I do PCO, and I also direct POCs done by good senior engineers. If it is poor, then I’m not good. The team weakness is the weakest of its members. But if it is a good team, the overall sum of strengths is lower that the integral team strength. Scrum or not, it is the way it is.
The team is responsible of the delivered solution, internal responsibilities are a must.
Simon: I don’t visualize an architect outside a team! So, I guess your point holds true.
If you have someone that is not in the team, it is not an architect, it may be a consultant probably.
Paul: Scrum is consistent with what I understand architecturing is. :-D
About the cahoots: I’ve seen the titled directors (PMs) in them, and some title architects there too, but the most I’ve seen is a CIO in the strategic seat and the architect in the lower floor with the rest of cubicles. I’ve seen that on very well know big companies. And the problem is that architects are not on those seats! Not the contrary. I see directors imposing restrictions to solutions: less time, less people, less money, use buzzword so we can show it in the tv ads, use that brand because if the one I saw in last night show, blah!
So, I guess you and I are in the same page, but blaming different people.
I don’t know what Simon means by Authority. To me, if a developer comes and says he wants to do this, and I tell him to better do that, and he says: I see, you are right, I now understand, then I know that I have authority. That is, I don’t need to be the paying guy, the one that can fire people, to be able to recommend something different. People will hear my suggestions because they know I know, and I have demonstrated that. So, authority is not about having power, but about been able to say: trust me, I know.
Now, If I say: good point, go ahead and let me know what happens, and the developer walks away proud his idea is a good one, I have authority. But If someone has to force the developer not to do something, then I guess something is not good there, and I have to demonstrate my point. I will probably end up with a POC, not take my point as granted.
Here is our take: Everyone starts developing. Some may show supervising skills, some will show abstraction and development skills, some will show research and people skills. So, training department start working on developing people to maximize their abilities. Some will go to QA, some follow the PM path, some will go to the Architecture path. Nobody is forced.
Now: I hope all this writing sheds new light on the discussion. We are towards the same, but with a different concept at the names.
William Martinez Pomars
Hi William,
Generalisations are always wrong :). An individual "Architect" is unlikely to fit the stereotype. Andy, Simon and I are talking about our experiences and how the label of "Architect" has been applied in practice.
I recognise the experiences described by both Simon and Andrew. I'm not sure that I recognise your experience. Perhaps your experiences are unique? Which could be a good or bad thing depending on your point of view.
My experience (in fact what I an now observing at m y current client), is that Architects are often in a position of authority soley by virtue of their position (similar to that CIO you describe).
My main concern is peer review and who finally decides. I also have sympathy with Andrews point as a Manager, needing to promote someone to the role of Architect in order to retain him/her and ensure that he/she is properly rewarded for their skills. Why can't that individual progress their career as a developer and still be appropriately rewarded?
You've said alot about what the role of an architect isn't. Why not explain what it is? I must admit, even after performing the role myself for 2-3 years I still haven't come up with a water tight definition other than technology selction and high level design. Incidently, these are things I still do now, although I no longer call myself an Architect.
Paul.
Paul.
1. The generalizations are always wrong, true. So why do you insist in saying all architects minus me are ivory tower guys that force developers to do what they as architects are guessing the client needs? I do know a couple too that are not like that (not completely). So, we are talking how it should be, anyway.
2. You mention Taylor, so I guess you know about management. Please recall Maslow's hierarchy of needs. The growth needs are far beyond just money and rewards. Taking new roles is a growth signal. Having people with role you like to achieve is something good.
3. I’ve been saying a lot what the architect is. There are several books on the subject too. Anyway, I promise I will either write a book or a series of posts to even clarify what it is supposed an architect has to do.
4. Finally, I guess there are people that don’t like to call themselves something. I don’t like to call myself “agile”, but still agree and do what the manifesto says (even before it was actually written). The good thing is not someone’s name, is what that guy is doing. If you do this, then you are in the good path, if I do that I’m too, so what is the problem about the names?
William.
William, I really liked your previous comments and it helped me a lot to understand your perspective. We really are very closely aligned on our thinking, the devil is in the details.
Yes - agile has now been degraded to nothing more than a buzzword, but that word does hold some meaning with like beliefs - but levels of understanding are all different and there is no way to standardize, so its all rather complicated. However, exactly the same problem exists with architecture, project management, business analysis, etc.
I don't quite agree with your point that agile people do care about the title though. Maybe some do - just as some architects care about their title, but I would much rather have someone that practices it than preaches it. Largely I want to avoid the 'a' word, I don't believe it helps any argument these days because its been abused so much.
Sorry if I suggested that architecture is merely about technology selection. It really does depend on the types of people you have worked with and where you have worked as to what people are called (job titles) and what they actually do. I have worked in positions where PM's have defined process and elsewhere processes have been defined by developers. Perhaps surprisingly, people whose job title is PM and part of their duties is to define development processes, do not do as good a job as this as the development team themselves. This, I believe can again be linked back to that Frederick Taylor thinking that people in one perceived position are not smart enough to figure out what needs to be done - others need to do it for them.
Many of these arguments are very dependent on context. The level of talent in a development team can vary greatly, and if you don't have a talented team, you're in trouble already. Again, Taylorist thinking comes in here by assuming that we can substitute talent for low cost resources, based on the idea that smarter people than they can simply tell them what to do and everything will be fine. Trouble is, software development is not a simple repetative process, its a complex, creative one.
Another good point to your argument, which is my fault for not making clear enough - I did not mean to suggest that a developer is merely someone who types code into the machine and compiles it - a 'coder'. Almost all of my development roles included my talking to clients to elicit requirements, some from of deciding on the most applicable process and practices, some form of architecture and design, testing, and implementation (coding).
Now, I tend to look for talented people who can also do these things, not just type in code. A huge problem exists here though - such individuals are very hard to find.
Perhaps I was a bit frivolous on the subject, but my reference to word play is related more to job titles that anything else. I don't disagree with the fact that architecture as you understand it happens on most projects, my real argument is - why should a project have a single point of authority called an architect, when any member on the team could be just as able to suggest the idea at the right team. Its all about the angle from which view what teamwork is all about and to me some job titles sound too 'command and control'. If you disagree with this - then why make statements such as 'Architect needs to make them commit to the system, and hear all what they need to say.'. Your customers don't have to commit to anything - its their money.
Looking at your comment 'The decisions taken must be understood by all, and approved too.' is also a little naive. As soon as the ink has dried on any approval, minds have already changed, so approval counts for nothing. Maybe you have been considerably luckier than I, but this has happened on every project in every organization I have ever worked in.
Agree on your communication point, code is not the only medium, it is the however the single most important thing though - not saying that nothing else matters, just that all others have a lower priority.
Hi William,
2. You mention Taylor, so I guess you know about management. Please recall Maslow's hierarchy of needs. The growth needs are far beyond just money and rewards. Taking new roles is a growth signal. Having people with role you like to achieve is something good.
This is just it. I don't believe this is something good. Being well rewarded for a job well done is good. Delegating decision making down to those who do the work is good. Working as part of a team with a common goal is good.
I believe in flat organisational structures. Creating tiers and reward schemes that incentivise people to set themselves apart from the team is not a good thing in my opinion.
It is a complex subject and difficult to approach without getting into generalities. Mary Poppendiek gave great presentation on InfoQ where she describes The Role Of Leadership In Software Development
It is a bit long, but well worth watching, especially if you want to explore the impact of poor management and poor organisational structures on the success of projects further.
Lots of interesting discussion. :-)
> Can you expand. I would assume that the team was is in a position of technical authority, not just the architect. If the team can't be trusted with technical decisions, then perhaps you need to change the team.
I do think that architecture is something that everybody should be involved in, but that doesn't happen, with most teams falling into one of two camps (I'm generalising slightly to make a point here).
(1) The architects sit outside of the team in ivory towers and the development team aren't empowered (there are very strict hierarchies in place, and the development team are constantly told, "you can't do that!"). The reason that this fails is obvious - architects need to be a part of the team.
(2) There is no formal architect, with the role instead being shared between the development team. While this might seem an ideal situation, it's rarely done in a Scrum-like way (i.e. where the team members are empowered) and frequently fails because "architectural" stuff falls between the gaps.
My experience comes from being an external consultant to many city (of London) organisations (e.g. banks), so unfortunately I'm not in a position to change the teams. What I can do, however, is help educate people on why architecture is important, and then guide them on doing just enough of it to make their project a success. I'd love to work with a team that was truly empowered, but I've not come across one yet! ;-)
Post a Comment