In the software world, many vendors architect, build and deliver their software for certain use cases and industries. What is becoming very clear is that the world is moving to introduce more rules and compliance requirements and it will be so in the coming decades, inducing architects to bolt-on or recode their software to respect that new rule. We have all been through the SOX, HIPAA (if you are in healthcare), Fedramp (if you sell to federal organizations) and now GDPR (if you have data in Europe). So if we expect in the next decades that new rules will arise, how many times do you need to go through your code and perform surgeries after surgeries? Well, it’s time for a new type of software architecture, a Regulated Oriented Architecture (ROA).
A Regulated Oriented Architecture (ROA) is a new style of software design where micro-services through configuration can respect any (new) compliance rules. It involves the logging of system, APIs, events and / or end-users activities on a reliable and scalable architecture (“the reflection”), the capability to purge or keep any data at any time, inside any storage based on any attributes (“the sweeper”) and through built-in algorithms proactively adjust its behaviour (“the guardian”) and expose its state directly to the lawmakers.
Key Issues
Two Worlds
Regulations and compliance rules are all complexes with their legal language that nobody understands except lawyers. At the same time, the legal side does not know how software is built except software engineers. The normal process today is that lawyers come up with a checklist being a summary of the law and then ask the software developers to go and change their code. The issue here is that these two worlds do not understand each other. So the result is that after infinite and never-ending discussions, software changes are delivered that may put at risk its value, performance, and scalability becoming the biggest risk for every software vendor (personally I may get a law degree at some point so that I can understand both worlds).
Effective dates
Another interesting behavior is the publication of rules and their effective dates. In the legal and software world, most of the firms ignore these new rules until consulting firms, to earn good money, start their (‘if you don’t do this, you go to jail”) campaigns to wake up everybody and deploy consultants everywhere.
Responsibility
In case of failure to comply with a (new) rule, who is responsible then? The legal advisor, the software vendor or … the customer running the solution within its IT department? But there is a twist to these questions: for customers who have chosen a cloud deployment, there is virtually no responsibility. Most of the liability is on the software vendor side (SaaS and IaaS vendors).
While the legal consultant is gone, who is responsible for complying with the rules? Exactly, the software vendor…that is why it is time is there to build software based on an ROA-based style.
The fundamentals of an ROA
There are three major areas in an ROA: data management, the artificial intelligence rules and its execution of archiving / purging and the reporting to the lawmakers.
Data Management
The new software system needs to support the configuration and change of its internal format. Essentially an eclectic behavior where XML payloads can move to JSON ones or a new one in the future. Management of data includes ten major aspects:
- Data storage ;
- Data formats;
- Data tagging;
- Data transportation;
- Data access;
- Data security;
- Data effective dates;
- Data ownership (system and / or user);
- Data manipulation;
- Data archiving;
Special data: users
In the next chapter will expand on each topic for Data Management, but we will expand on the Artificial Intelligence (A.I.) side and reporting capability. The goal is:
No more going through an entire code to apply a new compliance rule!
Massimo
All posts reflect personal opinion, vision and insights. Upon my approval, posts can be reused.
DECODING INFORMATION TECHNOLOGY 
Leave a Reply