Have you ever experienced technology- or vendor-centric architectures?
Our guess is you have seen something like this, because it is rather common. The rationale is often that we want a common technical platform (and software vendor) for all applications in a given area. This will ensure we have everything in the same solution and only one vendor, thus it is easier to reuse functionality and data. Furthermore, we can harvest synergies in development skill-sets, operational support and licensing.
What about discussing and analyzing requirements with the business stakeholders? Well, not quite so. The story goes that while there might be differences in business requirements from various business stakeholders, the major vendors are anticipated to be able to support the different business models and requirements. So why specify detailed business requirements? Doing so would be a waste of time – or even worse, it could be counter-productive, because the architecture is a given. Furthermore, we should adopt this as standard and not try to adapt it to our immature practices. And this helps to minimize the need for integration. The procurement then centers around selecting the software product with the best overall “software capabilities” for this type of system at the best price.
So why not embrace this approach as an architect? Well, here are eight good reasons based on our experience:
- Your internal alignment on common processes, common business rules, terminology and priority is not done before buying. Thus, leading to difficulties when the new software has to be configured. Perhaps even stressed by an optimistic implementation plan.
- Procurement as approach is often selected even before we know whether buying new software is needed.
- The standard applications on the platform that looked fine in the vendor demo turns out to require a lot of work to be usable. The largest consumer of time and cost is usually found in the integration into the existing eco-system.
- It turns out that the competency that goes with the new software, the so-called “best practice”, is not a good fit for your organization.
- It can be challenging to reuse functionality in a big commercial platform for other purposes than intended leading the organization to buying included functionality more than once.
- Organizational flexibility for changing business models, changes in organization or outsourcing is impacted as it cannot be done without changes to the whole system.
- The wide scope of the technical implementation will often lead to long release cycles because of the complexity of developing and testing on a large platform. This again will lead to bottle-necks and down prioritization of business needs in favor of compliance-related development.
- Product Ownership will not be business centric because the separation of concerns in the tool does not reflect your business. Product Ownership turns into a more technical product ownership.
This is why we believe in an outside-in approach. The outset here is to understand, which business requirements are common enough to be effectively solved in a common application. The rationale is to enable business agility by solving different “problem spaces” individually. This allows for a high degree of autonomous ownership, prioritization, funding, release-cycles etc. The use of same technical platform (and software vendor) is secondary to the autonomy of the application. The reuse aspect here is more strictly enforced as common applications exposing governed interfaces.
What is your experience with technology- or vendor-centric architectures?