How much architecture is enough?

Mon, 08 Sep 2008 16:01:00 GMT

Thanks to everybody that came along to our "in *our* brains" session last week where we tried to answer the question of how much architecture is enough. The event was part of Skills Matter's London Agile Month and it was a great turnout where we had some interesting disucssion ranging from what agile is all about through to how architecture tasks should be tackled during an agile project.

The set of slides that I used to set the scene can be downloaded from here (PDF, 0.9MB) and the video from the session can be watched from here (this includes the presentation and the discussion). Also, Alberto Brandolini has a really good blog entry, which covers the session along with some of his own thoughts that followed. See you next month!

How much architecture is enough?

Mon, 01 Sep 2008 10:11:25 GMT

This Wednesday, after the training course and as a part of Skills Matter's London Agile Month, we'll be running a session entitled "How much architecture is enough?". Although this is billed as "In the Brain of Simon Brown", it's actually going to be an "In *our* Brains" session where a few of us will be facilitating a group discussion.

As for how much architecture is enough, well we've touched upon this question before, particularly with respect to the level of design detail you should put in your architecture document and the need for just enough quality. While I don't think that software development is a relay sport, if you are planning on handing off your architecture, how much do you need to do to ensure that this exercise is successful? And on the subject of sharing architectures, how much should you share and are there more creative ways of efficiently delivering your message?

There's lots to talk about and if this stuff interests you, please sign up on the Skills Matter website. This will be the September London User Group and the session starts at 6:30pm.

When will the offshore bubble burst?

Thu, 14 Feb 2008 11:08:00 GMT

Hearing management teams talk about offshore is becoming a more frequent occurrence these days and most large organisations that I've met in the past six months are starting to invest in offshoring if they've not done so already. That's not really surprising when you take a holistic view of the economics, but I'm convinced that the current offshore bubble will burst in the next 1-2 years, making way for a much more collaborative model. Let me explain.

Most organisations see offshoring as a way to reduce the costs associated with software development. The basic premise is that "software development is a commodity" and that "commodity development is low risk and can be easily offshored". Effectively, organisations are taking a "software factory" approach to software development where they throw specifications/contracts at offshore teams and expect working software in return. There are a couple of points that I want to pick up on here.

Software development is a commodity : I've heard this a lot recently, from organisations on the buy-side and the sell-side (e.g. consulting companies and system integrators), but I don't agree with it. Software development is still a complex discipline and you can see this by taking a look at the rate of technology change driven by people trying to make development easier. Just look at how many Java web application frameworks are available. Sure, there are parts of software that can be and have been commoditised, but there's still a lot of bespoke development that goes around it.
Offshore reduces costs : The most compelling reason for organisations looking to adopt offshore is that "the daily rates are much lower for offshore resources than onshore resources" and if you compare them in terms of cold hard cash, you can't argue with it. However, I don't think that organisations are thinking about the additional investments that they need to make in order to give the current offshore model a chance of success.

For example, it's fairly safe to say that most organisations work in a fairly ad hoc manner and need to put some investment into improving their processes to enable offshore development to work. This might include improving the way in which requirements are captured, prioritised and documented before even thinking about how best to structure the overall solution and define the work packages/specifications that will be sent offshore. Plus, you then have to factor in the additional cost of testing that will undoubtedly take place when the end-product has been developed and the potential latencies that will be introduced from teams being distributed across the globe. Sending work offshore introduces work onshore to manage it.

If you're reading between the lines, you might be thinking that I think offshoring is a bad idea, but that's not the case. The same problems apply regardless of where the "external" team is based because you've artificially introduced barriers that prevent the teams from successfully working together. Offshoring just makes it harder because of differences between time zones, cultures, etc. What you have here is a distributed waterfall model of software development.

Requirements : The buy-side organisation figures out what they want, scopes it and defines it.
Analysis : The buy-side organisation analyses the problem and starts designing a high-level solution. Anything from a small component to the full solution is documented in enough detail so that an external team can understand and deliver the solution. I've even heard of teams that take this process down to the pseudocode level!
Design : The offshore team take the analysis and start designing software.
Implementation : The offshore team implement and unit test their code.
Test : Depending on what they are developing (i.e. a component or a whole system), the offshore team performs some higher level testing before shipping the deliverables back to the buy-side for further system and integration testing. The usual quality assurance/bug fix cycles commence, with enhancements and change requests being sent offshore.

Our experience in software development has proved that the waterfall model doesn't work in many cases, for a number of reasons. These range from not delivering a fit for purpose solution because the requirements change once the design is "signed off" to actually failing to deliver at all. Plus, from an architecture perspective, handing-off your architecture to the development team also reduces your chance of a successful project. I've been called in to look at a lot of poorly performing, unscalable, etc solutions recently where the architecture hasn't been thought out well enough. The software factory approach to software development needs well defined signed-off specifications for it to work, but that's the one aspect of software development that we know just isn't possible (in the commercial world, anyway). If organisations can't get software development right using this process with an onshore team, how are they going to get that same process to work with an offshore team? Offshoring has the ability to reduce costs, but you're making some trade-offs.

No, the real problem here isn't offshoring, it's the engagement model that organisations are using. I think that, for offshoring to work, the engagement model needs to move away from the distributed waterfall and towards something that is more inclusive, collaborative and iterative. Agile methods bring everybody together and focus their efforts towards a common goal, which is the same thing that needs to happen with offshoring. Offshore teams need to be fully brought in to the overall software project that they are helping to build and the focus needs to switch from seeing them as a service provider to seeing them as a part of the team. More involvement and more collaboration is what I think will help make offshoring a successful approach. In fact, let's not even use the term "offshoring", let's just think about this as a distributed project team.

To wrap-up; I don't think that the current "software factory" approach being adopted by most organisations is healthy or sustainable, and organisations are starting to become dissatisfied with the results they are getting. Waterfall approaches have failed in the past, what's different this time?

Simon Brown - agile tag

How much architecture is enough?

How much architecture is enough?

When will the offshore bubble burst?