Comments on: Agile Software Architecture: The smallest change with the highest business value http://blog.xebia.com/2006/11/29/agile-software-architecture-the-smallest-change-with-the-highest-business-value/ Software development done right! Wed, 08 Feb 2012 14:41:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Maarten Winkels http://blog.xebia.com/2006/11/29/agile-software-architecture-the-smallest-change-with-the-highest-business-value/#comment-1224 Maarten Winkels Tue, 05 Dec 2006 06:46:59 +0000 http://blog.xebia.com/2006/11/29/agile-software-architecture-the-smallest-change-with-the-highest-business-value/#comment-1224 Hi Lars, I agree that the term Architect is a bit fuzzy and overused these(?) days. What I try to do is point out a task in an agile project that could be assigned to the 'architect' role: Focus on small changes. As you point out, no one can better determine business value than The Business. Normally, they have a feel for what features are needed. What they normally do not have a feeling for is the cost of those features. This cost comes in two (or more?) forms: Implementation and Integration. Within an Iteration, it's the task of the developer to estimate the cost of implementing a certain requirement and discussing the cost/value with The Business. This will lead to an Itartion planning, that may span multiple iterations, as certain requirements will be pushed out to future Iterations. There also is the cost of Intergration. Determining this cost involves knowlede of the technologies used by The Business and the systems they run. What I try to put forward is the notion of the changes that have the lowest cost in this respect. Implementing these requirements first will help The Business bring the new system to production without large interrupting changes. Maybe this could be termed 'Scope Management' or 'Scope Planning'. The project should start with a small scope and gradually enlagre the scope. I would think of a 'Scope' as a grouping of requirements. This would mean for instance that the long term target of a new system is replacing the numerous old systems. While this is the long term target, it's scope is too big to handle at once. The project should focus on a smaller scope first. Regards, -Maarten Winkels Hi Lars,

I agree that the term Architect is a bit fuzzy and overused these(?) days. What I try to do is point out a task in an agile project that could be assigned to the ‘architect’ role: Focus on small changes.

As you point out, no one can better determine business value than The Business. Normally, they have a feel for what features are needed. What they normally do not have a feeling for is the cost of those features. This cost comes in two (or more?) forms: Implementation and Integration.

Within an Iteration, it’s the task of the developer to estimate the cost of implementing a certain requirement and discussing the cost/value with The Business. This will lead to an Itartion planning, that may span multiple iterations, as certain requirements will be pushed out to future Iterations.

There also is the cost of Intergration. Determining this cost involves knowlede of the technologies used by The Business and the systems they run. What I try to put forward is the notion of the changes that have the lowest cost in this respect. Implementing these requirements first will help The Business bring the new system to production without large interrupting changes.

Maybe this could be termed ‘Scope Management’ or ‘Scope Planning’. The project should start with a small scope and gradually enlagre the scope. I would think of a ‘Scope’ as a grouping of requirements.

This would mean for instance that the long term target of a new system is replacing the numerous old systems. While this is the long term target, it’s scope is too big to handle at once. The project should focus on a smaller scope first.

Regards,

-Maarten Winkels

]]> By: Lars Vonk http://blog.xebia.com/2006/11/29/agile-software-architecture-the-smallest-change-with-the-highest-business-value/#comment-1212 Lars Vonk Mon, 04 Dec 2006 22:06:10 +0000 http://blog.xebia.com/2006/11/29/agile-software-architecture-the-smallest-change-with-the-highest-business-value/#comment-1212 Hi Maarten, Are you saying that it is the architects responsibility to determine which changes have the highest business value? I think this should be customers (or The Business) responsibility (e.g. the product owner in Scrum), the architect (or every other software developer) can help the customer by providing input if needed. Although I doubt if he can because in most of the cases the customer doesn't even know what the business value of a change is. Architects (or developers) can say something about the impact. Also I think it's too difficult to say that an architect should have a certain role in an (agile) project. This because I have heard too many types of architect these days (software architect, business architect, business process architect, functional architect, integration architect etc.) There has already been a lot of debate going on about what an architect is and should do, integration is one of the more important tasks I guess. But if you say the main focus of an architect is determining which changes would be best to implement, then a better term would be consultant. Or even better a business (:-)) consultant, because that is then his main job: Consulting the business what changes should be implemented. Groeten, Lars PS. Having all this said I am suddenly realizing that this is exactly what the BIA in Xebia stands for: Business Integration Architects. We have been Agile from the start! Hi Maarten,
Are you saying that it is the architects responsibility to determine which changes have the highest business value? I think this should be customers (or The Business) responsibility (e.g. the product owner in Scrum), the architect (or every other software developer) can help the customer by providing input if needed. Although I doubt if he can because in most of the cases the customer doesn’t even know what the business value of a change is. Architects (or developers) can say something about the impact.
Also I think it’s too difficult to say that an architect should have a certain role in an (agile) project. This because I have heard too many types of architect these days (software architect, business architect, business process architect, functional architect, integration architect etc.) There has already been a lot of debate going on about what an architect is and should do, integration is one of the more important tasks I guess. But if you say the main focus of an architect is determining which changes would be best to implement, then a better term would be consultant. Or even better a business (:-)) consultant, because that is then his main job: Consulting the business what changes should be implemented.

Groeten,
Lars

PS. Having all this said I am suddenly realizing that this is exactly what the BIA in Xebia stands for: Business Integration Architects. We have been Agile from the start!

]]>