2.4 Laws, regulations and standards

While laws and regulations rarely force any technology selection, they sometimes guide what you are and are not allowed to do with technology. That may impact your technology selection, especially if the law forbids certain activities and the technology you are considering does precisely that. As an architect, you should be acutely aware of the laws and regulations impacting your environment, as failure to do so could lead to severe consequences for your organization.

For example, in Europe, the General Data Protection Regulation (GDPR) concerns processing Personally Identifiable Information (PII), which defines fines for infractions. The implications of GDPR are significant, as a breach could lead to substantial fines. The AI Act also defines high-risk AI use cases as those requiring mitigations and certain AI use cases as illegal. Again, implementing a forbidden AI use case may lead to a fine, not a small one. These regulations carry significant weight and should be thoroughly understood.

There are also standards like The Payment Card Industry Data Security Standard (PCI-DSS), which covers the implementation of payment processing. While not exactly a law, the banking industry has both self-regulated itself, and many supervisory authorities may again order fines for significant infractions. You should be aware that when a standard becomes widely adopted, it may become soft laws, sometimes guides to interpreting hard laws.

It is not possible to list all laws comprehensively. You need to determine which laws and soft laws are relevant to your field. Document them and their core requirements. Take those into account when selecting any major technology. Most of the time, there won’t be anything related to your work under those laws, but you can never afford not to ensure that. For instance, the maximum fine under the GDPR can reach up to € 20 million or 4 % of a company’s total worldwide annual turnover from the previous financial year, whichever is higher!

As an architect, you should know the most common IT-related standards and their core concepts. While most of them don’t force the selection of technology again, they impact how technology operates, and you may need to include some of those things in your requirements. If you work in an established enterprise, there is already a set of agreed standards, and you will not be allowed to ignore them. Your knowledge of these standards is crucial to your role.

ISO standards are also common. The core idea of ISO standards is that quality means no surprises - everything should always work as defined. First, you define and document how something should work. Then you make it work exactly like that. Some personnel training is probably involved. Then you set up supervising to ensure it always works like that. Then you bring in the auditor, who finds it works like you documented and gives you a nice certificate.

Information Technology Infrastructure Library (ITIL) is a framework for IT service management. It’s not an official standard per se, but companies use it widely. The origin story of ITIL is that the government of the United Kingdom developed it to ensure that vendors tender similarly, making it possible to compare tenders. Nowadays, IT departments worldwide attempt to follow the core principles of ITIL, and if you bring new services into the mix, you are sometimes required to implement ITIL processes.

The Control Objectives for Information and Related Technologies (COBIT) and the Business Technology Standard also focus on managing IT to maximize business potential. The core value of these frameworks is that they offer a common language for business and IT leaders. They provide an excellent background against which to communicate your ideas but rarely impact your technology selection.

The Open Architecture Framework (TOGAF) is the only widely adopted architecture standard. It focuses on Enterprise Architecture governance processes and complex beasts that a large committee could have built. A distinct pro of the standard is that you can get training and certification for it. The major downside is that no one will ever be able to implement more than a fraction of TOGAF before they run out of resources.

The Center of Internet Security (CIS) publishes Critical Security Controls, a great collection of the most common IT security requirements. They also publish benchmarks tailored for several standard software pieces. We should mention Cyber Security Framework 2.0 from the National Institute of Standards and Technology (NIST) because governmental agencies apply it. The point of mentioning these is as potential starting points if you are missing security requirements for your IT systems.

12-factor app principles are best practices for building modern, scalable, and maintainable cloud-native applications. They cover aspects like configuration management, stateless processes, and portability. While not a formal standard, they’re widely adopted because they align well with microservices, DevOps, and cloud computing. Software rarely fully complies with 12-factor app principles, but you may want to require them to guide an implementation.

OpenAPI is a framework for defining and documenting RESTful APIs. It enables developers to describe endpoints, parameters, responses, and authentication methods in a clear, machine-readable format. OpenAPI definitions ensure easy interoperability across system, team, and company borders thanks to their automatically generated interactive documentation. OpenAPI is one of the tools you may require to ensure that something has an API that others can use without extra hurdles.

If you completely ignore the commonly adopted standards, you risk interoperability issues and having to build tools for already solved problems such as security. You may also inadvertently create a special lock-in to your implementation that is uncommon in the field. That will lead to maintenance overhead and cause extra work your developers do not find meaningful.

However, you may deviate from the standards when you have a clear justification. You know why you must deviate, what it will lead to, and how to manage the risks. Standards are often generic and don’t consider all of your requirements arising from your unique environment and use cases. Ensure you never ignore a technical standard without understanding what you will forget and why.

Sometimes, you should create your own standard. Not in the way a large standardization body works, but just enough to be able to mandate your vendors follow that contract. You need some solid engineering for that, but standards defining how interoperability between systems should work or how critical API you want complete control over may be promising tools to decouple essential components.

For example, businesses requiring tracking certain materials may buy an RFID tracking system for warehouse management. Those systems are readily available. However, every major RFID tracking vendor wants to provide their warehouse management system. That would be a major vendor lock-in because you must train personnel for that specific system. It is much preferred by the business if the disruption of changing the UI of the system never happens and the tracking system integrated into the ERP system is already in place. Developing a standard REST API using OpenAPI definitions to implement the interface into the ERP system would be a good solution. Every vendor providing RFID tracking is going to have to implement that because it enables relatively easy replacement of the RFID tracking systems.

Many vendors claim their proprietary solutions are standards while they are not. You should also evaluate whether those standards exist and are open and leverage commonly used technologies or APIs. Keep in mind that standards exist for interoperability. A standard known or followed only by one vendor doesn’t typically provide much value for your company. In that case, you should dictate how things work.

As an architect, you should know the laws and regulations impacting your company. Your goal will not be to become an expert on them but to ensure you will not cause a considerable compliance issue down the road with your technology picks. You should gravitate towards following the relevant standards in your field. You must find out which ones unless someone has already done that work. Then, you have to distill requirements for your solutions out of them whenever they are relevant to your outcomes.

If you have a legal department available to assist you with these and you can’t find previous work, please ask them to help you identify everything you need.