3 ms·

While one can think of every problem as a snowflake situation never encountered by anyone before, outside of its core business domain an organization (particula

While one can think of every problem as a snowflake situation never encountered by anyone before, outside of its core business domain an organization (particularly a non-technical one) rarely faces truly unique challenges. Most of the time one can also decompose the solution into a number of well-known problems that had been solved before. For example, in an overall solution for some snowflake business challenge you may see components such as an order taking system, a customer support center, a CRM, an ERP—and on another level patterns like a statically rendered site, an SPA, a “classic” content-driven site, and so on. In my opinion, being blind to these opportunities and intent on putting the entire solution together without any delegation of control flow smells of lazy architectural thinking and/or job security. The exact decomposition would depend on business specifics, foreseeable future evolution of the business, team capabilities and other factors, but as a result you’d be able to radically lighten the implementation and indeed maintenance burden with a strategic use of frameworks or even lightly customized CMS.

marcus_holmes 4y ago
This simply isn't true for, well, every project I've been on. There is always some unique wrinkle in the requirements that means this project needs a different approach. SAP is the classic example of this: SAP implements vanilla business processes (with lots of flexibility built in). Yet every single business implementing SAP needs extensive customisation and modification to make it fit their business processes. Some have spent millions or tens of millions trying to make SAP fit their business and failed. In your terms; every business is a snowflake. You cannot create (for example) an order taking system that will fit all businesses. Or even "all businesses for whom order taking is not part of their core business domain". Only "those businesses who are willing and able to make their order-taking process fit your system".
- strogonoff 4y ago
  You identify common aspects and snowflake aspects, and in the end the separation as to which parts are snowflake (contain business specifics). That’s your job as software architect. Again, the locations of snowflake parts tend to be similar across businesses, and this is where good frameworks and CMS tend to offer extension points. It’s a spectrum: a CMS may be more fiddly as to customization but more reliable if your needs and extension points fit, framework offers more freedom, and a bespoke combination of libraries generally forces you to implement and integration test more of control flow and imposes higher costs of maintaining proper documentation as to how everything fits together (to avoid the next engineer accidentally killing performance due to a misunderstanding of how it’s supposed to work). On the other hand, CMS and frameworks can actually inform your decisions, as their engineers had faced tasks similar to yours time and time again.
  - marcus_holmes 4y ago
    I work in startups mostly, where requirements are not defined and the business learns as it goes; it's simply not possible to identify all the areas that are "snowflake" ahead of time. It is sometimes possible to persuade the business that if they create the process in a way that matches the framework it will make life easier for everyone. But often that isn't possible, and often there are good reasons for that.
    - strogonoff 4y ago
      I see. When writing my comment I also had in mind all the businesses that are not primarily technical (shops and such). I think it’s often possible to identify the truly inflexible/snowflake aspects the business and still make use of frameworks/CMS. For a tech-focused company there are possibly more cases in which building your own is a viable decision, but with other companies that don’t have strong technical brains so to speak “this will cost you more to develop and more difficult to hire for later” is something they would understand…
- dublin 4y ago
  <quote>Some have spent millions or tens of millions trying to make SAP fit their business and failed.</quote> Any business that tries to make SAP fit their needs will fail to some degree (usually to a large degree, and expensively). SAP will tell you in a heavy German accent that you bought the perfect business practices from them, and if you want to be successful, you VILL make your business fit SAP, not the other way around. In reality, they're right - All the really successful SAP installations I've ever seen had the company tossing all of their existing processes and replacing them wholesale with the ones built into SAP. Trying to make SAP fit foreign practices is a losing deal.
  - marcus_holmes 4y ago
    Yeah, I've heard the same. And this echoes what I think happens with frameworks. You cannot make the framework fit your process. You might be able to make your process fit the framework. But the further your ideal process diverges from the framework's process, the more painful it is and the more the benefits of getting started faster are lost. :s/framework/SAP/g

marcus_holmes 4y ago

This simply isn't true for, well, every project I've been on. There is always some unique wrinkle in the requirements that means this project needs a different approach. SAP is the classic example of this: SAP implements vanilla business processes (with lots of flexibility built in). Yet every single business implementing SAP needs extensive customisation and modification to make it fit their business processes. Some have spent millions or tens of millions trying to make SAP fit their business and failed. In your terms; every business is a snowflake. You cannot create (for example) an order taking system that will fit all businesses. Or even "all businesses for whom order taking is not part of their core business domain". Only "those businesses who are willing and able to make their order-taking process fit your system".

strogonoff 4y ago
You identify common aspects and snowflake aspects, and in the end the separation as to which parts are snowflake (contain business specifics). That’s your job as software architect. Again, the locations of snowflake parts tend to be similar across businesses, and this is where good frameworks and CMS tend to offer extension points. It’s a spectrum: a CMS may be more fiddly as to customization but more reliable if your needs and extension points fit, framework offers more freedom, and a bespoke combination of libraries generally forces you to implement and integration test more of control flow and imposes higher costs of maintaining proper documentation as to how everything fits together (to avoid the next engineer accidentally killing performance due to a misunderstanding of how it’s supposed to work). On the other hand, CMS and frameworks can actually inform your decisions, as their engineers had faced tasks similar to yours time and time again.
- marcus_holmes 4y ago
  I work in startups mostly, where requirements are not defined and the business learns as it goes; it's simply not possible to identify all the areas that are "snowflake" ahead of time. It is sometimes possible to persuade the business that if they create the process in a way that matches the framework it will make life easier for everyone. But often that isn't possible, and often there are good reasons for that.
  - strogonoff 4y ago
    I see. When writing my comment I also had in mind all the businesses that are not primarily technical (shops and such). I think it’s often possible to identify the truly inflexible/snowflake aspects the business and still make use of frameworks/CMS. For a tech-focused company there are possibly more cases in which building your own is a viable decision, but with other companies that don’t have strong technical brains so to speak “this will cost you more to develop and more difficult to hire for later” is something they would understand…
dublin 4y ago
<quote>Some have spent millions or tens of millions trying to make SAP fit their business and failed.</quote> Any business that tries to make SAP fit their needs will fail to some degree (usually to a large degree, and expensively). SAP will tell you in a heavy German accent that you bought the perfect business practices from them, and if you want to be successful, you VILL make your business fit SAP, not the other way around. In reality, they're right - All the really successful SAP installations I've ever seen had the company tossing all of their existing processes and replacing them wholesale with the ones built into SAP. Trying to make SAP fit foreign practices is a losing deal.
- marcus_holmes 4y ago
  Yeah, I've heard the same. And this echoes what I think happens with frameworks. You cannot make the framework fit your process. You might be able to make your process fit the framework. But the further your ideal process diverges from the framework's process, the more painful it is and the more the benefits of getting started faster are lost. :s/framework/SAP/g