Coding the Architecture - requirements tag

Why do so many technology projects fail?

Fri, 23 Nov 2007 14:48:00 GMT

The Financial Times published an interesting article earlier in the week entitled Perspectives: Why do so many technology projects fail? (registration required) detailing a court action between BSkyB and EDS. In summary, it's about the failure to deliver a software project, how software projects aren't like construction projects, how a new way of working is needed, etc, etc. It's all stuff we've heard before and, as the article says, are lessons never learned?

Why do so many technology projects fail? Here are my thoughts, some of which overlap with the FT's article.

Iterative and agile techniques have revolutionized the way that software development is performed, but our industry needs to take a step back and look at the way in which software projects are engaged. Why, when you read about so many high profile big budget software failures, do businesses still initiate software projects with "we want this, tell me how much it will cost"? *We* know that they'll change their mind. *They* know that they'll change their mind. So let's change the engagement model, stop hiding behind fixed price contracts and work *together* to solve problems.
In my opinion, the view that software development is a commoditized skill is wrong. This is regardless of whether software is developed on-shore, off-shore, etc. Software development is a discipline that's part engineering and part art. If you want decent software built, don't treat it like a commodity. You wouldn't want anybody to build you a Ferrari, would you?
And finally, of course, there's the lack of a technical architect. Not all architects sit in ivory towers throwing unworkable "solutions" at development teams. Some of us like to work *in* the development team and eat our own dog food. Think of how many software projects you've seen that function correctly but are not fast enough, scalable enough or secure enough. That's why you need an architect.

I was chatting to Sam yesterday and he has some interesting thoughts too, which I'm hoping he'll write about one day. Something that we both agreed on though, is that the software industry generally needs to learn some lessons and wake up to some of the shortcomings that are so prevalent today.

Scaling is much more than software

Tue, 24 Jan 2006 22:21:38 GMT

From Scaling is much more than software comes this great little snippet about one of the ways to solve problems with your architecture.

What was the solution? Re-evaluating the business logic and requirements with the customer.

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 business analysis - 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.

Business analysis?

Thu, 19 Jan 2006 09:55:51 GMT

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.

Business analysis - that's not part of my role is it?

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.

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?