http://www.codingthearchitecture.com/tags/analysis/ Software architecture for hands-on software architects en Coding the Architecture Fri, 26 Sep 2008 13:09:00 GMT Pebble (http://pebble.sourceforge.net) http://backend.userland.com/rss http://www.codingthearchitecture.com/2006/01/24/scaling_is_much_more_than_software.html <p> From <a href="http://www.mosseri.org/blog/archives/2006/01/scaling_is_much.html">Scaling is much more than software</a> comes this great little snippet about one of the ways to solve problems with your architecture. </p> <blockquote> What was the solution? Re-evaluating the business logic and requirements with the customer. </blockquote> <p> Whenever I'm talking to aspiring software architects about the role, I always find myself emphasising and re-emphasising that an architect must take both the functional and the non-functional requirements into account when designing a system. This reminds me of the previous question about <a href="http://www.thepragmaticarchitect.com/2006/01/19/business_analysis.html">business analysis</a> - it's certainly part of the role and, as an architect, you shouldn't be afraid to question the customer's expectations, particularly if you feel that they are going to adversely affect other aspects of the development. Architecture, and it's success, is about balance. </p> http://www.codingthearchitecture.com/2006/01/24/scaling_is_much_more_than_software.html#comments http://www.codingthearchitecture.com/2006/01/24/scaling_is_much_more_than_software.html Tue, 24 Jan 2006 22:21:38 GMT http://www.codingthearchitecture.com/2006/01/19/business_analysis.html <p> One of the aims of this site is to help highlight that fact that an architect's role isn't purely technical. Alongside being a technical authority, making technology decisions, coming up with architecture, design, etc are other responsibilities. Recently, I was asked the following question by an aspiring application architect. </p> <blockquote> Business analysis - that's not part of my role is it? </blockquote> <p> In my view, the answer is yes because for an architect to successfully bring together the functional and non-functional requirements into a working system, they need to understand those requirements. In the most part, this understanding comes from analysing the requirements further, often by talking to people such as the project sponsor, business users and even the dedicated business analyst team (if applicable). To my mind, most developer roles also have an aspect of business analysis in them - it's unrealistic to expect somebody to build a system if they don't understand (to some degree, anyway) exactly what it is they are building. This is even more important at the architect's level. <p> <p> So to answer the original question, yes, business analysis is part of an application architects role. What do you think? How does this match up with your experiences and expectations? </p> http://www.codingthearchitecture.com/2006/01/19/business_analysis.html#comments http://www.codingthearchitecture.com/2006/01/19/business_analysis.html Thu, 19 Jan 2006 09:55:51 GMT