Have you ever experienced technology- or vendor-centric
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 flexibilityfor
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
- 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 out-side 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