In classic "build or buy" scenario for infrastructure-related (application architecture or development architecture) solution, in 90% of cases my answer will be "buy".
Some hate me because of that, but I won’t change my mind. Even if you have a reasonable developer manpower, it’s better to utilize it on building business scenario-related functionality than on creating something that has already been built 1 million times in a generic-enough way. Simply speaking - just don’t re-invent the wheel. If there are several solutions available but none of them meets your requirements, then maybe it’s you who do something not right, don’t you think? You’re not that "special", sorry (or rather - you shouldn’t be).
Some recent scenarios I’ve recommended "buy" over "build":
- package manager
- configuration server
- service broker / saga pattern implementation
But (there’s always a “but”), if we’re talking "build or buy" in the context of business-related functionality, whole story gets more complicated:
- Infrastructure-related solutions are more easily classified due to following (usually) some widely known patterns - so it’s easier to evaluate those or just establish valid set of expectation for vendor enquiry
- Uniqueness is much more a benefit for business-related solutions than for architecture solutions
- There’s already some kind of ubiquitous language engineers use to describe purely technical solutions ("request - response", "synchronous vs asynchronuous", "one-way", "MOM", etc.) and it simplifies the analysis - it’s not possible to create something similar for business solutions (due to massive diversity between those)
Don’t fall in a trap - vendor who sells you some package will always tell you:
- "it’s trivial to integrate"
- "it uses WebServices so integrating is a piece of cake"
- "it covers all the scenarios internally, so you just start it and it works"
- "you can make it running in a no-time"
These are LIES. You can call those simplifications, but the world “LIES" describes it better. Why?
- Integration is always the most risky and time-consuming part of the project - due to synchronization, different knowledge level on both sides, problems with unclear responsibility, different urgency on both sides, communication misunderstandings and technology-related differences.
- What kind of problems did I personally encountered during packaged solution integration:
- misunderstanding of the assumed functionality (it offers something different, or in a different way) aka “gaps”
- tricky technical quirks - stateful vs stateless (expected), assumed (but non-existing) scalability, insufficient security standards
- insufficient or not-precise-enough documentation
- business people want to customize their solutions to distinguish their offer in business market - sometimes it may not be clear that the customization level (in a given tool) is not sufficient
In other words - if you’re about to buy a package, but you don’t understand it fully - don’t risk it, perform a full analysis, search for gaps, evaluate. Don’t be afraid of PoCs - it may cost you a bit, but it may save you much more. And don’t let anyone convince you that integrating packaged solutions is quick and easy (unless you know them perfectly already).