Service v manufacturing

I do most of my banking on-line, its dead easy. The bank run all the software on their server. Because they control all of the code on their server its super easy for them to change it when they want, how they want, for whatever reason they want. Lets call this the service model – roughly 1 chunk of code used by many users.

I also have a car, this is handy for getting around, but not as much fun as a bike (in the sun). I bought it and I keep it at home, like many people. If the manufacturers find a problem they then have to issue a recall notice, every customer has to get their vehicle back to a dealers to get it fixed.

Duke with axle scare

Every new vehicle we have bought has had at least 1 recall. My Ducati recall was for a potentially terminal rear axle failure – I had to ride it 100 miles to the dealers in the rain knowing that someone recently died when their axle broke without warning – nice ride (not). This is clearly not as handy as the service model, but its hardly insurmountable.

Lets call this the manufacturing model, each user get their own copy of the product.

Now you have to have been hiding under a big stone for a long time not to have noticed the increased interest in the service model of delivering software. In part related to the massive uptake of t’interweb. I reckon even the most zealoty Web 2.0 zealot would accept that there is still a place for distributed software in the manufacturing model style. Do you agree?

I guess all those forecasting the imminent death of the desktop, probably don’t agree? And we have been having an interesting discussion around App level or WB level code, which is pretty much the same issue.

I’d say all versions of Visual Studio after VS6 (ie all the .net ones) have been pretty much exclusively focused on the service model of software delivery. The recent versions have pretty much ignored the manufacturing angle. Hence why many standalone apps are written in Delphi or C++.

I’d say MS Office (well all desktop s/w really) follows the ‘manufacturing’ model, as do many of our solutions built on top of it. MS have a pretty smooth patch process, as demonstrated with the recent Excel calc bug fix, issued within a couple of weeks, and about to be automatically pushed out to clients. (The Windows update bit seems a bit ‘flaky’ though!)

Most Excel users are also following this manufacturing style too, build a model/report, email it out. Email a correction when an error is found. Copy and paste data from one to the other as required.

I can’t help feeling MS have lost the love for this manufacturing model s/w though.

And I think a lot of software devs are now nervous of widely distributing software, in case they need to make a change. They prefer the safety net of server based services that they can change/fix as needed. On the one hand that is prudent, on the other hand aren’t they(/we?) just a bunch of big scaredy cats? Or is the security requirement of working in an always on, always connected environment just so great, that old style is no longer viable?

At the end of the day, for most of us (certainly in business apps development) a problem in the software we write is an inconvenience (possibly expensive), but not life-threatening like the Duke axle issue.

Shouldn’t we be focusing on writing good software instead of avoiding the issue by concentrating on delivering our work in a way that makes it easy for us to correct our blunders later?




12 Responses to “Service v manufacturing”

  1. Dick Kusleika Says:

    Separating code from data isn’t a desktop vs. server issue. How much data is stored in excel.exe or msword.exe? None. The reason Windows Update works is because it doesn’t try to replace the registry. It updates the code and the new code uses your old data.

    And it’s not about writing good software. Anyone who writes bug free software that never needs new features either writes useless software or is a liar. So yes, let’s focus on writing good software AND let’s focus on delivering the software in way that doesn’t inconvenience the user.

  2. Rob Bruce Says:

    It’s not just about having to re-distribute if you find a bug.
    The main reason I prefer the service type model is flexibility in the face of business change.
    It’s business management who are the real scaredy cats – they’re the ones who won’t commit themselves to a definitive set of business rules, a finite set of requirements or a fixed application scope. They’re so eager that the business should move forward at such rapid pace that they’re unable and even unwilling ever to envisage how the business actually works at any given time.
    I don’t want to distribute 1000 copies of my app 5 minutes before I get the call saying “Oh, and another thing…”.

  3. Marcus Says:

    Hi Simon,

    I like your analogy between the service and manufacturing models.

    Probably one area (I’d like) to create a further distinction in, is between patches and enhancements.

    The axle on your Ducati (nice bike btw) was a structural flaw (bug) which compelled a fix (patch). But if Ducati were offering a different shade of amber indicator covers because they gave ‘better’ night vision to oncoming traffic you may not be bothered driving the distance if you didn’t feel it was a compelling reason to upgrade.

    With the service model we don’t have that choice and that’s a bug-bear for me. When the Outlook 2000 security patch came out it broke some of the code I’d written for a client. You now had to manually accept (click a button) that another program was trying to send an email via Outlook/Exchange. However, the client had a choice as to whether they wanted to implement that ‘patch’ (they just didn’t research or test the repercussions properly). Imagine if your bank updated their software (without forewarning) that you needed to do a retina scan every time you wanted to do a funds transfer. Oh man; you mean I need to go out and get an iris scanner? What if I don’t want that enhanced security ‘feature’. Um… tough.

    The Outlook patch was a knee jerk reaction on behalf of Microsoft so maybe it was not be such a good example. But it does highlight that people had a choice to install the patch or not. Some people are happy enough with O2K, would SAAS compel them to upgrade? When ‘invisible’ updates occur on a server, we may not feel the repercussions until it’s too late.

    You can probably tell, at heart I’m still a thick client guy.

    Cheers – Marcus

  4. Simon Says:

    Who was talking about separating code from data? I’m talking about centralised v decentralised systems, rather than any internal structure.
    And what are you calling spreadsheet formulas? code or data?
    I think we agree on your last para, but possibly we have a different view of inconveniencing the user?

  5. Simon Says:

    Good point on changes.
    My experience has been that getting the 1,000 out the door (well, not that many) is quicker than setting up a service style system. And payback often starts sooner in the project.
    I’m thinking you (and others) have maybe invested more time and effort in components that support service style systems than I have? So you can maybe meet the same delivery schedules by leveraging that?
    I have the investment in distributed patching instead.
    Interestingly I have a big patch project on hold at the moment, I bet if it was service based (not sure if thats possible/realistic in this case) it would have been agreed and rolled out by now.

    Good points Marcus, I hadn’t thought of the choice aspect – but now you’ve got versionitis!
    I wonder if there is a definitve answer
    if this this and this then service based
    if that that and that then distribute and patch
    else blah blah
    I kind of think I should be looking more at the service side, but then with some of my clients I’m locked out of doing that properly and end up dropping back to distributed. Food for thought anyway.

  6. Dick Kusleika Says:

    *I’m* talking about code vs. data. That’s the reason I make add-ins instead of putting code in spreadsheets. Does someone else do it for a better reason?

    I call formulas code. However, I can’t separate formulas from data. I would if I could, but I can’t. VBA I can separate, so I do.

    No doubt our opinions differ.

  7. Dennis Wallentin Says:

    The Ubuntu Linux distribution is in many ways an interesting platform. One of it’s advantages is that we can update all softwares in one go. The key here is that it goes beyond the manufacturing model as it allow us to update all installed softwares.

    I would like to see that the Windows platform moves in this direction.

    The overall question I see is:
    Why do we need to care for updates in the first place?

    Whenever I’m connected to internet new updates / patches should be automatically installed.

    Perhaps this is the key to why the web platform looks more and more attractive as whenever we get connected to our bank etc we always use the latest versions.

    BTW, quality goes never out of style. For several years ago the bottom on the inner tent to one of our Hilleberg’s tent got exhausted. When Hilleberg received it they concluded it was a manufacturing error so they replace it with a new inner tent to no costs at all for us. (Now they got additional goodwill when I communicate this story!).

    Kind regards,

  8. Dennis Wallentin Says:

    Simon – Could You please collect my latest comment here from the WordPress spam bin (as I was not logged in…)


  9. Jon Peltier Says:

    Dick & Simon –

    In an ideal situation, there are really three levels: Business logic, Data, and Presentation. Business logic includes the code and formulas which drive the model, and these can exist separate from the other levels. Data is data. Presentation is the combination of data (extracted from the data layer and processed by the business logic), code (vba and formulas), and display elements (worksheet, chart, and other graphical elements) that make the interface between the application and the user.

    Many smaller spreadsheet apps have all three layers mashed together, often in an unholy mix. In most of my apps, the demarkation between the layers I’ve informally defined above are blurred, and the boundaries are dictated as much by logistics and convenience as by any rigid definitions.

  10. Simon Says:

    I like Auto updating it theory, but it relies on a large amount of trust:
    And as Marcus says, sometimes we might know more than the vendor and not want a certain patch.
    Jon I do n-tier in the sheets for any significant wb, unless I can get the data into a db. I dont think many systems manage to fully stick to it though.
    There are plenty of people who prefer a document flow style:
    I’m not sure that scales well, might work for smaller stuff though.

  11. Harlan Grove Says:

    When ‘business logic’ means well-defined calculations, worksheet formulas should be how it’s implemented. There may be cases in which udfs would be more efficient and/or more reliable, but at that point spreadsheets may not be the best platform. VBA is most useful for preprocessing (importing when queries aren’t practical or possible), postprocessing (printing and saving) and in conjunction with user-initiated actions.

    Skipping to presentation, spreadsheets are very useful, but there are lots of things they don’t do well. For example, the canonical method for showing summary statistics and associated detail data is putting the summary formulas ABOVE the data detail and freezing the pain containing them. Then the detail data could be scrolled while the summary calcs remain on screen. It’d better if there were 9 panes rather than 4, e.g.,

    A B C
    D E F
    G H I

    where A, C, G and I don’t scroll, E scrolls left/right/up/down, D and F scroll up/down with E but NOT left/right, and B and H scroll left/right with E but NOT up/down.

    Sometimes VBA is necessary in order to achieve specific presentation characteristics within Excel, but if the worksheets were rendered in a browser, then formulas alone could generate the necessary formatting tags. Be interesting if there were a spreadsheet that could generate CSS files, but I’d guess that’d require some means of identifying which specific parts of each worksheet should be rendered as a table, which text in specific locations, and which text that the browser could flow according to the user’s browser window layout.

    Finally data. There’s a huge difference between spreadsheets used for reporting or analysis of INTERNAL data and spreadsheets used for decision support using mostly EXTERNAL data from customers or intermediaries. The bulk of the data I work with comes from the latter class, and a considerable part of my job involves ETL.

    If I used mostly in-house data, I’d use simple data queries, with each query in a different worksheet, and those worksheets containing ONLY the query results (hence my expressed desire for future versions of Excel to provide Table sheets which would be entire sheets that would only contain a single table with NO other cells, and such Table sheets would only support structured referencing), then use formulas in other worksheets to fetch the data they need.

    I believe in keeping data (especially user entries) separate from formulas, and I always include the rows above and below and columns to the left and right of entry ranges when naming those entry ranges, and I use lookup or index formulas to reference data.

    In multistep systems, e.g., contract pricing for large financial services deals (e.g., group health insurance pricing in the US), when most of the data involved requires user entry rather than database feeds, the model calculates statistic based on that entered data as initial indications of contract pricing terms, but final values are subject to user judgment. It’s ideal to group multiple related entries into the same worksheet, even stacking separate but related data entry sections in different groups of rows within the same columns, and also to show initial indications and final user selections in the same place to make comparison easier. For the latter, I combine simple formulas referencing the indications (calculated in different worksheets) along with entry cells for the user selection entries. So I’m not an absolutist about keeping data and code separate. There are situations in which it’s not practical.

    As many have written, whatever works best is best. The problem is that whatever works best isn’t the same in all circumstances.

  12. Harlan Grove Says:

    And now to address your topic: manufacturing vs service.

    I don’t accept Excel + add-ins + XLS and XLT files as manufacturing vs VSTO and whatever as services. As long as the pricing model remains flat charge for as much or as little use as the user/buyer wants/needs, the distribution and maintenance channels will be nonissues for most users/buyers.

    Dispersed applications that don’t require constant access to centralized data sources will have an advantage when users would need to use them when they don’t have net[work] access. That may not describe most corporate reporting or financial trading systems, but it does describe many front line sales decision support/pricing systems.

    As net[work] connections become more ubiquitous and PCs become connected almost all the time, centralization has economic benefits that are hard to ignore.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: