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?