Software Architecture within a Commercial Context

Inspired by a recent post by Paul Reedman I was driven to make this response, before diving in let me go on record and say that having been a readers of Paul’s Blog for while now I usually find myself saying ditto to all his post.

But this one and in particular the responses which it generated has fired me into action.

The line "In the software industry it's all about writing code and getting a product out the door. Good design and architecture has disappeared." Sends the message, to me at least, that somehow we have sold off good design for the sake of money or commercial pressures.

I can understand those comments but I also need to say that is not way it has to be, in fact it is only that way in some organisations because us as a group of Software Architects have not been innovative enough to prevent this from happening.

My view point is this, Software is developed within a commercial context and the commercial model of supply, demand and free market forces needs to drive everything we do. Recent history has shown us this is a force that can’t be resisted.
So as Architects we need to embrace this reality, much like many of us have embraced change as a fact of every project we all need to embrace commercial constrains of time and budget and design around it.

Now that does not equal compromise rather it should cause us to innovate. Let me share some experiences here in short form, I will save the details for a book, or for the next time we have a drink together.

• Just Like Any Other Feature - Get the time and budget constrains into the project requirements and map the relationship between other constrains and these commercial ones.

• More bang for the buck – Everything needs to used more than once, write development documents that can be rehashed for user documentation, use API test suits as a basis for API Client libraries, practice OO reuse all the time. (Email me if you want more of these ideas I have hundreds)

• Less is more – Be strategic why spec two functions that have 70% overlap, give it one use case and extend it, same applies at implementation stage.

• Use a pattern – Patterns are distilled experience which is free and only have a positive impact on the project, so understand them and use them all the time.

• Parlay It Up – Stop looking at projects in isolation, ask yourself what is one thing we can do that will have less than a 1% impact but give us some value that we can use in the next project. (Poor man’s framework and code base)

• Don’t remake the wheel. For the pride, if there is a third party component, server, application, API, whatever that can help you deliver; trade some budget to save some time. Clearly do this with care; it can work out if you do your homework.

• Show me the Money – Releasing early and releasing often not only keeps a client happy but can work to simply your project. Something magical happen you make the client live and breathe an early version of the application. They start to discover how they can optimize the functionality and this can highlight the useless stuff that can be cut.

Now that I made all the motherhood statements let me hit with some hard realities. You cannot change the laws of physics; total project budget divided by time constraint divided by the number of plan iterations will always limit what one can achieve.
The defining factor of a software architect and where the art comes into it is how much you can achieve with what you have to work with.