Architecture Therapy
Menu
  • Home
  • About this blog site
  • About the authors
  • Sounding Board
Menu

Belief #6 Best architectures are contextual

Posted on December 15, 2019December 16, 2019 by Lomholt, Pedersen & Pushpala

Have you ever been told that you could save a lot of time and discussion if you adopted a standard and then safeguarded it with no customisations?

The rationale behind the statement is typically that you should not invent it yourself when there is a well-recognized international standard. However, we have more than once experienced that adoption of standards working elsewhere fails when applied to our own similar businesses.

One set of standards are architecture reference models for capabilities, processes, services and information concepts etc. For example, introducing a generic data reference model can lead to ambiguity and complex mappings when you try to apply it to a business with different rules and use of concepts. Similarly, mandating a reference business capability model with a functional split and terminology that does not reflect the actual business leads to a lack of business recognition and commitment. In both these cases the mandating and making a standard mandatory limit the flexibility and challenge the organizational memory. Best architectures take the outset in the accumulated body of knowledge and practice created in the course of the organization’s existence.

Another set of standards are reference models for ways of working and ways of organising with standard roles and forums etc. For example, imposing a strong data asset culture on an entire organization will work in some parts, but not in others as their problems and solution more require a process modelling or capability-based approach.

If you forego to match your way of working with context you may jeopardize years of valuable learning on how to work effectively together by insisting on one-sizing. So perhaps the way forward could be a connected co-existence and the question to solve in this example would be how to connect a data asset, process or capability (i.e. how do should they restrict, scope, guide or inform each other).

Using standards “as they are” makes sense for industry comparisons or cross-organisation exchange of information e.g. for SWIFT payment message between banks. But if you want to apply a standard to your internal organisation it must be tailored to your context, its history and its people. Trying to make your organisation fit into a standard will lead you nowhere.

Standards can be valuable as a starting point because they represent learning from someone else. But we have to take the implementation serious by asking ourselves,

  • What is the problem we are trying to fix? For example, lacking business involvement will not be solved by introducing an external standard.
  • What is the scope of the standard? It might cover less or more than you need in your situation
  • Are the standard terms recognized and mean the same in your organisation? Sometimes a lot of changes will be needed for your stakeholders to understand and accept it
  • Is it so generic that it will take a lot of interpretation and mapping to use it?
  • Can you “profile” it to your organisation in such a way that it fits into existing concepts, functions and practices that you already have well in place? And if you need to make many changes is it then worth the effort?
  • Does it assume a specific business model or organization setup? Sometimes standards assume a front-office vs back-office setup or the use of specific technology
  • If it comes from a start-up company developing one app would it work well in an old institution with complex legacy and systems of systems?

The promise of avoiding endless discussions with standards is a dangerous one. Especially when little care is put into the implementation other than certifying employees in the “vanilla” standard. Not few leaders have decided to adopt a standard, made it mandatory for all to use, and perhaps even provided a tool for everyone to use, and after a while realized that it is not having the intended effect. In many cases the reason for the failure is stated to be bad change management in the implementation, but often it could just as much be that it is the wrong solution for the problem.

We believe that best architectures – based on standards or not – are contextual to given business area, the specific situation, the people in it and their experience.

What is your experience?

1 thought on “Belief #6 Best architectures are contextual”

  1. Pingback: Architecture beliefs and why they matter - Architecture Therapy

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Categories

  • Architecture Beliefs
  • Outside-in

Recent Posts

  • Our value proposition May 11, 2020
  • Belief #10 Best architecture practices value communication and stakeholder engagement over intricate modelling May 2, 2020
  • Belief #9 Best architectures are scoped top-down and validated bottom-up April 6, 2020
  • Belief #8 Best Architectures are embedded with the change organization March 17, 2020
  • Belief #7 Best architectures keep together what is common and separate what is not February 12, 2020

Recent Comments

  • Belief #9 Best architectures are scoped top-down and validated bottom-up - Architecture Therapy on Belief #2 Best architectures are developed iteratively
  • Belief #9 Best architectures are scoped top-down and validated bottom-up - Architecture Therapy on Belief #5 Best architectures enable organisational agility
  • Architecture beliefs and why they matter - Architecture Therapy on Belief #8 Best Architectures are embedded with the change organization
  • Belief #9 Best architectures are scoped top-down and validated bottom-up - Architecture Therapy on Belief #7 Best architectures keep together what is common and separate what is not
  • Architecture beliefs and why they matter - Architecture Therapy on Belief #6 Best architectures are contextual

Disclaimer:

The views, thoughts, and opinions expressed in this blog belong solely to the authors and are not necessarily the views of the respective companies and organisations we work for.

 

Contact us:

if you have questions or general feedback - please reach out to us at info@architecture-therapy.com
© 2021 Architecture Therapy | Powered by Minimalist Blog WordPress Theme