I agree with your comment - in the end it comes down to what is core to our business, and what is not.

We may be able to use a CRM system off-the shelf. However we get to that starting point, we will need to fill in quite a bit around it (ourselves) in order that we can get to 20x client numbers whilst maintaining only a small team (and few physical locations).

The “Marketing Management System” will increasingly be a core part of our competitive advantage (i.e. it already is, but it’s just in my head at present - one of our challenges is to get it out of there and into a tangible form that can be scalable, and sustainable).

Cheers

Paul

Just to keep this in perspective….Ford had a huge IT department for the maintenance and delivery of their internal applications. Most of it outsourced to Compuware, and as the product manager responsible for Fords application development platform, I’ve had more than a few trips to Dearborne.

An internally built application needs to be integrated with other applications and it needs to be maintained. Maintenance can become an ‘interrupt’ to regular business.

This is an excellent detailed overview to augment the notes Stephen put together earlier.

Just a couple of clarifications from my frame of reference:

Engineering is more than just bridges

I would re-iterate the comment I made on Stephen’s post - in the same way that others outside the software space might have a simple view of Software Engineering, so should caution be advised when looking at other engineering disciplines too simply:

Yes, Software is not a Bridge, but there are many other examples that have plenty in common with the software process.

I talked about the difference between design and manufacture here. In other engineering domains (any time a novel product/asset is being developed) part of the design process will also include experimentation in terms of how to manufacture.

Jack Reeve’s article is about a Design/Manufacture paradigm (not Engineering)

I read this copy of “What is Software Design?”. Not sure if this is 100% the same as the one Neal Ford refers to.

I can personally remember the debate about whether software was an engineering discipline - back when the article was written (1992) was just after I graduated and there was no software engineering discipline at university. Rather, there was a “Computer Science” degree shoe-horned into the Science Faculty at UQ. Those who were interested in software (not me at the time) did a degree in CS coupled with a Electrical Engineering degree.

Certainly, the profession of software engineering has come a long way since that time.

I understand the reasons why it is important to clarify the distinction between Design and Manufacture as I did here (even in red), and to point out the reason why software engineering is predominantly a design-centric process.

I fully support this distinction as I see it will lead to better software being developed (i.e. through Lean/Agile and other processes).

However, I think a cold shower is needed for anyone who continues to believe that:
“The final goal of any engineering activity is the some type of documentation” (from Jack’s article). It was wrong back in 1992 when the paper was written, and it’s still just as wrong today.

I have friends in many different disciplines of engineering (my degree is in mechanical) and, if they heard a statement like that, they would collapse in fits of laughter!

The ones who would laugh most are the friends I have who are Manufacturing Engineers. Under Jack’s perverse logic, these friends would see the untenability of their position and vanish in a puff of smoke!

My friends the Construction Engineers would also quake in their steel capped boots waiting for the anti-matter to get them, too.

Don’t get me wrong - I think Jack’s article is quite good.

1) Back in 1992, Jack should just have stayed away from a woefully incomplete metaphor about the full scope of engineering - as this just serves to close doors and further confuse people.

2) However, that was back in 1992, when the debate about whether software was a real engineering discipline was all the rage. Why anyone continues to quote something like this now is beyond me.

Jack sums it up much better in his summary:

“Programming is a design activity—a good software design process recognizes this and does not hesitate to code when coding makes sense.”

I agree with this entirely!

By inference, he even makes a good point to sum up when to code and when to put something in another form of document (e.g. Design Specification) - i.e. only when it does not make sense to code.

Hope this clarifies things.

Paul