Good vs. Bad & Ugly: Comprehensive vs. General Design
The difference between "Comprehensive Software Design" and "General Software Design" and why Comprehensive is the only way.
Let's assume a simple categorisation of business into trade and manufacturing.
Most of the companies that are active in a category, arrange and manage their processes - despite different fields of business- inspired by a similar and close to optimal pattern. For example all trade companies share the same processes and concepts such as sales region, sales commission, petty cash and etc. The pattern is called best practice.
What happens if you decide to design a comprehensive information system for trade firms? As you know their requirements and best practices, supported by the trade business knowledge and understanding which you have already earned during last 25 implementations, you design a model that, with minimum complexity and maximum clarity, covers most of the a typical trade firm' processes. Not only your model but also your user interface are efficient and understandable by the customer.
This is what I call a Comprehensive Design.
Obviously the model doesn't cover all processes in all trade firms but, those non-covered are a small fraction compared to what the model already covers. In fact, your model embraces about 80 to 85% of a typical trade firm's processes which leaves you 15 to 20% customisation during an implementation. The percentages I just mentioned are very famous in ERP world.
Clearly, the knowledge of a typical trade firm requirements and best practices which you've acquired during your 2 implementations -even if both were successful- is not extensive. So when designing you have take care of all the possible requirements -which you're not aware of yet- by designing facilities to easily change the behaviour of the model. This is the key characteristic of your design, happening all over your model since you don't know the real world's requirements and need to prepare for meeting them.
Actually, your model is a General Design.
It doesn't have a skeleton -the extract of your experience and knowledge- rather it has lots of lots of features that help users customise all the aspects of it and all because you don't know what you'll be facing in a typical trade firm.
There is a design principle stating that "The design and usage complexity of a software is proportional to how much the software is generalised." In other words, the more general your design the more difficult its development and usage.
Because it is complex and doesn't have a real structure, the result is not a software that has a shape but such a flexible set of -sometimes inconsistent- customisation features that it hardly has any shape. Practically, you have to create a new software out of all the customisation features, In every implementation using the general design.
“Do not generalise. Generalisations are generally wrong.” -Butler Lampson
Image source: fansshare.com
Most of the companies that are active in a category, arrange and manage their processes - despite different fields of business- inspired by a similar and close to optimal pattern. For example all trade companies share the same processes and concepts such as sales region, sales commission, petty cash and etc. The pattern is called best practice.
Good
Now, imagine that you have designed and implemented information software for 25 trade companies so far; naturally resulting in your extensive knowledge of trade firms' processes and requirements -put simply, best practice. In other words, you do know what the customer wants and needs.What happens if you decide to design a comprehensive information system for trade firms? As you know their requirements and best practices, supported by the trade business knowledge and understanding which you have already earned during last 25 implementations, you design a model that, with minimum complexity and maximum clarity, covers most of the a typical trade firm' processes. Not only your model but also your user interface are efficient and understandable by the customer.
This is what I call a Comprehensive Design.
Obviously the model doesn't cover all processes in all trade firms but, those non-covered are a small fraction compared to what the model already covers. In fact, your model embraces about 80 to 85% of a typical trade firm's processes which leaves you 15 to 20% customisation during an implementation. The percentages I just mentioned are very famous in ERP world.
Bad and Ugly
Now, imagine a totally different situation: you have designed and implemented information systems for 2 trade companies so far and all of a sudden you decide to design an information systems for trade firms in general. Let's see how your design is.Clearly, the knowledge of a typical trade firm requirements and best practices which you've acquired during your 2 implementations -even if both were successful- is not extensive. So when designing you have take care of all the possible requirements -which you're not aware of yet- by designing facilities to easily change the behaviour of the model. This is the key characteristic of your design, happening all over your model since you don't know the real world's requirements and need to prepare for meeting them.
Actually, your model is a General Design.
It doesn't have a skeleton -the extract of your experience and knowledge- rather it has lots of lots of features that help users customise all the aspects of it and all because you don't know what you'll be facing in a typical trade firm.
There is a design principle stating that "The design and usage complexity of a software is proportional to how much the software is generalised." In other words, the more general your design the more difficult its development and usage.
Because it is complex and doesn't have a real structure, the result is not a software that has a shape but such a flexible set of -sometimes inconsistent- customisation features that it hardly has any shape. Practically, you have to create a new software out of all the customisation features, In every implementation using the general design.
Final Words
- Comprehensive design is based on business knowledge, understanding the target market requirements and best practices and experience.
- Comprehensive design is easily grasped by users and it is easy to use.
- General design is based on a considerable technical knowledge, little business knowledge and incomplete understanding of the target market requirements and best practices.
- General design is complicated and not friendly from the user's perspective.
“Do not generalise. Generalisations are generally wrong.” -Butler Lampson
Image source: fansshare.com
The above is an interesting and thought-provoking post. My apologies for not having read it sooner.
ReplyDeleteI spent 30 years designing/writing software for/in the same industry – Mortgage Lending. First for that industry as a coder in a software house that served that industry and then as a coder in a Mortgage company that was, obviously, in that industry. I can tell you now that the second role was infinitely easier.
I am positive that it is only in the second environment that the "Comprehensive" category of design can even exist.
To take your point: "In fact, your model embraces about 80 to 85% of a typical trade firm's processes which leaves you 15 to 20% customisation during an implementation." and replace "trade" with "mortgage", then the statement is completely untrue. It does not embrace anything like that percentage. The software house had around 40 to 50 implementations of it's mortgage system and all were very different. Sure many of the differences were trivial and common to all, like "Company Name" on letters etc. and sure, those differences were easily "parameterised". But more than many of the differences were significant in terms of design and coding effort. Also, continued maintenance and enhancement of each of those systems often broke the initial design so severly that you might as well start with a "clean sheet" (and we often did).
I doubt very much that this state of affairs is unique to the mortgage industry but I do know that a "system" would have to be very trivial to conform to your idea of a "trade firm's" system. The software house's mortgage system had around 400 files and 2000 programs. In the second half of my career, in-house at a mortgage company, those numbers kept growing.
The only way that we, as a software house, could reduce the workload involved in another implementation was to dictate that companies' workflow/procedures etc. You can imagine how many of our new customers accepted that. The only time that we were sucessful was when the new customer outsourced not only the system but the entire operation of processing mortgages and we did have a couple of customers that did that with us.
You see, when someone is in the market for a non-trivial software system for their business, it is overwhelmingly because they have started a new company in whatever industry they have chosen. They have "spotted a gap in the market", seen a new way to "do" whatever it is, a quicker way, a way that takes advantage of new laws, new technology advances and so on. The result is that they want something very different – not something you have been selling for 20 years.
As you can see, this article piqued my interest, and thanks, my interest needs piquing more often.