Conversation about an Agile Architect

Conversation about an Agile Architect
Posted by Viktor Grgic mid-afternoon: January 4th, 2008

This is a short and sharp conversation over ICQ between two Xebians about what an Agile Architect is or does. The conclusion is that an Agile Architect has, in addition to Agile manifesto, a number of principles:
- Just-in-time and just-enough architecture
- An architect is a "waste" and has no direct business value.
- An architect should have or make a business case about his value for the team.
- An architect spends more time in facilitation of good ideas and matching these with the business and enterprise aspects than defining one by herself.
- An architect emphasises "what" is needed above "how" should be achieved.

Erik: So what's agile in your architecture?
Viktor: It is the way the architecture process is done. Just in time, just enough architecture.

Erik: How is this done? Do you conceive everything?
Viktor: An Architecture is not conceived, but emerges during the architecture process based on requirements, ideas from different people, and so on.

Erik: Why do we need architect for this? The team could do this too...
Viktor: An architect spends most of the time on:
- listening to people (both technical and business) and making sure requirements, risks, constraints, ideas and so on match.
- making views and viewpoints on many different areas (e.g. security, application management) based on the concrete needs and concerns of the stakeholders. Nobody needs huge documents and diagrams with 100+ elements.
This requires specific knowledge and deep understanding of technology and business which developers usually don't have.
It is also a balancing act between short-term real business results and long term business & IT strategy and translation of this strategy.

Erik: But if you trust the team to take care of the architecture and you accept that architecture emerges, then it can be also done by the team and scrum master?
Viktor: An architect takes care of the business & It alignment, requirements management, influence of the business strategy on system development. Does the business strategy allows you to go for short-term solutions and how much quality do we need? How is that reflected in the architecture? The team and scrum master does not have this broader picture.

Erik: No, I'm saying that that team *knows* the strategy and what the effects are on the architecture.
Viktor: But there is more: political and organisational aspects, security (combination of both technical and procedural aspects), integration, service-orientation. It becomes very difficult for a team to comprehend all this.

Erik: Still the team should also be responsible for these aspects.
Viktor: What you would like to have and the reality is quite different. Especially in the case of complex business problems and many stakeholders (e.g.: government and large organisations).

Erik: An architect is a creator of the system, he makes the blue print. This definition comes from building industry.
Viktor: Well, an architect should not be a designer. In the building industry, you have engineers who do that. The focus is on "what" and less or not on "how". What is needed to meet the business requirements. Maybe not an IT solution at all.

Erik: Now we're getting somewhere.
Viktor: An architect thinks differently and has different perspectives, qualities and knowledge to simplify things.

Erik: An architect helps the business define what is needed and inspires the team in meeting the business needs.
Viktor: Exactly!

Filed under Agile, Architecture | 3 Comments »

3 Responses to “Conversation about an Agile Architect”

Peter Says:

Posted at: January 4, 2008 at 8:36 pm

>> An architect is a “waste” and has no direct business value.

A very dangerous principle I really dislike.

>> P1: Why do we need architect for this? The team could do this too…

It depends on the definition of an architect. If you define a (software) architect as a senior senior developer, I would expect him to be responsible for the architecture of the application.

Even Jeff Sutherland has an architect on each of his teams ‘a single wringabe neck’.

>>P1: But if you trust the team to take care of the architecture and you accept that architecture emerges, then it can be also done by the team and scrum >> master?

It depends partly on the amount of knowledge on your team. But often there are some architectural patterns you can use to provide a lot of value. So someone who is aware of such big bangs for the buck, could save a lot of time. And by not having someone responsible for the quality of the software, the quality is going to suffer from different styles, dry problems, tight coupling/low cohesion and this is going to lead to spaghetti code (I have seen my share of spaghetti code caused by dogmatic usage of scrum).

So I think people should get over their ‘we don’t need an architect’. I think ivory tower architects are dangerous, but a hands on architect with more than average experience (technical lead) should be mandatory on every large project.

Mary Says:

Posted at: January 5, 2008 at 11:27 pm

Hi all,
First of all i would like to wish you and your beloved a very happy 2008.

At work (large governement organisation) i am writing about the strategic (business) goals in relation to SOA and v.v. Helping to formulate advantages and trying to let them see how we can go about aligning business and IT and why we should. In fact trying to educate my fellow workers (most of them are architects of the digital kind). You know, the ones that give a lot of developers a headache. There is a lot of missionwork to do in realtion to SOA.
Both on their side as well as on the business side.
Although they say i am, i am not an architect.
I am more an advisor on strategic business matters or what you can call a policy consultant. BTW: The latter can give developers a headache too
Architects come in all sorts. You don’t need the apparatsjiks; you need the one(s) with the big picture.
Perhaps you should check this out: martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Our philosophy teacher told us that he uses the following rules (and adviced us to use them too):
tolerate ambiquity, beware of understanding, think for yourself, make your own effort to acquire knowledge and bravely give your own opinion.
I see we do and i like that.
Mary

Quirijn Slings Says:

Posted at: January 20, 2008 at 8:12 pm

In my opinion, an architect is simply an experienced developer who has been involved in so many projects (good and bad) that the business finally decides to listen to him/her BEFORE the project starts..
And since I don’t think a business should ever start a project without listening to an IT-person first, I believe that an architect should be involved in any project that might be IT-related.