
This is a series of articles on culture, but this one is more of an architectural principle. I do consider it a cultural point to circulate, though, as many people in a company can influence new systems indirectly or directly (ahem, "shadow IT").
At former gigs, we tried to place business systems into one of three categories to help determine the best architectural option when fulfilling new capability solutions in those systems. This is based on Gartner's Pace Layered Architecture model. It is a good model, and it doesn't have to be applied all that deeply to give you quick and consistent direction.
Systems of Record are those things that most businesses do, and they do it in a generally similar way. Human Resources, Finance, Legal, etc. (Your situation may vary). These types of system are important for running your business, but they don't bring a lot of uniqueness to your business. Therefore, you do not want to invest effort into custom building these. There are many mature applications out there for them, and even better (cost permitting), you can find platforms that cover many of them (ERPs). Sounds kind of boring, but these are very important, and probably contain a large amount of your critical master data.
Systems of Differentiation are more unique. Definitely not something every company does, but also not so unique that others in your industry don't also have these systems. That said, while others in your industry do this, maybe you need to be able to configure it slightly differently in order to differentiate your company. Perhaps this is taking payments, your sales process, or last mile delivery. These systems should use best-of-breed applications or other SaaS software that allows some configuration.
Systems of Innovation are where your competitive advantage is. This is the stuff that makes your company unique; what you are trying to do that others cannot do. As such, it makes sense that this is where you invest in building it yourself.
Now, as an Enterprise Architect, I realize that these principles are best when they have some flexibility to bend against the needs of the real world. Schedules and budgets can be a decider. The pre-existing application ecosystem can influence your choices. So, while these are guidelines to drive the right choices, don't use them with complete rigidity to force you into bad decisions. But, if you've struggled with the buy vs build question, I hope you can see how this is a very easy classification model to point you in the right direction.
Comentarios