1 month ago

Belief #3 Best architectures are based on an outside-in practice seeking to enable purpose driven business outcome before optimizing the use of material or technology

Link: http://architecture-therapy.com/belief-3-best-architectures-are-based-on-an-outside-in-practice-seeking-to-enable-purpose-driven-business-outcome-before-optimizing-the-use-of-material-or-technology/?utm_source=rss&utm_medium=rss&utm_campaign=belief-3-best-architectures-are-based-on-an-outside-in-practice-seeking-to-enable-purpose-driven-business-outcome-before-optimizing-the-use-of-material-or-technology

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 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
    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 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
vendor-centric architectures?