I have decided to bring forward the publishing date of my new book, which is available on Amazon as paperbackand e-book (Kindle)
The book is entitledEnterprise Systems Architecture : Aligning Organisational Business Operating Models to Technology Landscapes
Fig 10 in the book – The updated Stack will be available on request, as an A0 poster, for academic reuse and described in the book.
Recently I was asked to sit in on an interview for a role of an Interim Solution Architect. Obviously, it would not be prudent to discuss the client, candidate or outcome. However, I thought I would share my expectation of a generic thought process from the candidate irrespective of the domain or technology stack they were to operate in with you.
My preference, as those who know me, is to use a whiteboard i.e. put forward a simple scenario to allow the candidate to discuss using a whiteboard. This can result in an interactive session, establishing a rapport rapidly and focus on the candidate’s skills, thought process and a deep dive into why choices are made.
The above becomes a challenge when faced with the dreaded telephone/skype interview, as the process becomes more formal and difficult to manage during periods of silence.
So, this, my first short blog of 2019, is not about any interview techniques, styles, questions or structures – I’ll leave that to others better qualified than me to address.
This posting is a discussion on a flow of thought used by Solution Architects or those interviewing to establish a common understanding, summed up in the mind map below and discussed briefly further.
However, I purposely exclude the Technology / Domain Experience which should also be addressed during the interview;
In most cases the candidate will be presented with a brief case study before the interview for example, “we wish to apply a value adding widget as an extension of our existing service portfolio – let us know your approach and the issues you feel you may face”.
Understanding the Desired Outcome
Every Enterprise Investment (things, people, time, money etc) is made to achieve a desired end state. So, during the interview it is important that the candidate reinforces his / her understanding of the value proposition of the project, technology or the end state deliverable in terms of both the business and technical outcomes.
The way requirements are discussed can say a lot about a candidate e.g. if they focus on a standard functional and non-functional requirement for the widget, this could illustrate a bias (like me) towards traditional system approaches to building systems. However, if they discuss the ‘use cases’ or ‘user stories’ for the widget, they may favour the agile approach to building systems which can align the candidate to the style of your organisation – just a thought.
The above is quite important depending on the type of organisation or project they are being interviewed for and sets the baseline for subsequent questions.
The Problem to be Solved?
The problem must be clearly articulated and identified and can be addressed through multiple lenses, like most things, there is never a right or wrong answer. However, at a minimum the following should be discussed;
The Business issue to be solved if any? If there is no real problem to be solved e.g., we simply wish to increase the production of widgets then it can be discussed as increasing efficiencies, sales, revenues, profits etc. The Business Case could be addressed e.g. if we are looking to efficiency gains, this may be done by leveraging or amending a set of existing or new business processes.
Technical problems are easier to address, as they are often binary, in part i.e. either wrong, or right? Which is dependent on the technology stack being discussed.
Often a mix of both Business and Technical problems can result in specific issues which could be articulated e.g. slow performance of an Application Server may result in long user wait times – affecting the ability to respond to customer queries in a timely manner resulting in loss of revenue.
Constraints / Limitations
When interviewing a Solution Architect, if they articulate the possible constraints or limitations in delivering a solution from past experiences, then that is a plus, typical issues that could be addressed are;
The Market Forces/Conditions which restrict certain actions e.g. the ability to switch products due to supply constraints or limitations for delivering certain services in specific markets the company operates in.
Government / Compliance –being aware of the various regulatory requirements, the bribery and corruption act, data privacy across markets – for global organisations issues regarding data residency and reporting may be a topic of discussion.
Funding / Resources – being asked if funding is approved and resources available is a basic question I would expect to be ‘mentioned’ during the solution options stages below.
Presenting the Options
This is a key skill – defending the option selected – See previous Blog – Options (do nothing, configure, amend/refactor, build, buy).
Defining the Solution
When interviewing a Solution Architect, it would be prudent to ask ‘what artefacts would you expect to produce/deliver’, answers should encapsulate at least a Level 0 design then High Level and Low-level Designs.
The solution when discussed should highlight an understanding of Non-Functional Requirements (NFRs) and I would expect a discussion around DR, Performance and Security Models at a minimum.
It is important to establish the candidates preference for ‘notational standards’ before discussing the definition of the solution e.g. are they familiar with Unified Modelling language ,(UML) , Business Process Model and Notation(BPMN) etc.
Once the options and solution are discussed the next set of questions should focus on the activity that the architect would undertake to deliver the solution – i.e. deploy the system into production often referred as the ‘route to live’ (R2L).
To end this short blog, I would say that Interviewing for a Solution Architect has two parts excluding the HR elements (team work, people skills etc) , which are;
- Business Domain or Technology Knowledge
- Approach when moving from a Problem to a Solution
I’ve kept this blog entry very brief on purpose as I feel this topic is worthy of a few chapters in a book, but I hope it helps.
Firstly, if like me you are tired of the constant stream of General Data Protection Regulation (GDPR) waffle, presentations, blogs, tweets & experts then I apologise in advance.
Last week I asked a former colleague, who had been working in the weeds of GDPR for the past year, “what does the DPO do on a daily basis?” the reply being “see articles 36 /39 of the law, I don’t know what they do on a day to day basis in our organisation” – which caught my attention.
Having studied the actual text of the GDPR in detail when it was first released (see previous blog) and subsequently presented Enterprise Architecture perspectives in terms of impact on the technology landscape and business operating models in early 2017, I felt the need to write an addition to the previous blog.
The reason for my interest is due to the fact that last week I was asked by an Organisation if I would consider being their external Data Protection Officer (DPO) – a medium sized organisation which has grown organically in the past decade to achieve an annual turnover of £60M+ with offices around the globe and a business model that manipulates and shares both internally (internationally) and publicly a constant stream of personal information on its current and future customers/suppliers.
Before we start, I must stress that as a DPO one is not personally liable for data protection compliance. The controller or processor remains responsible to ensure compliance with the GDPR. However, a DPO plays a crucial role in helping the organisation to fulfil its data protection obligations providing oversight to minimise risks.
In many ways, with regards to the obligations of the GDPR the title is somewhat self-explanatory. It screams data protection by an individual empowered to protect both the organisation and subjects against possible data misuse or retention by providing a level of due diligence and oversight of data privacy across the organisation.
I must stress that the DPO has a duty of care to the organisation, to minimise any privacy processings threats that could result in possible fines and can be achieved by understanding both the strategic and operational use of data within that organisation together with its Business Operating Model.
To simplify the role of the DPO we can break this into 5 segments which are discussed in no order ;
Monitor Organisation Internal Compliance
As a DPO you must have oversight of all the formal and informal data controls in terms of ingestion, extraction, manipulation, transformation and exposure / publication of data within the organisation.
During any new project or programme of work, individuals will be tasked to ensure that Data Protection Impact Assessment (DPIA) is completed as a core project artefact / deliverable and identifies and minimise risks. The DPIA will encapsulate at a minimum (Information Commisoners Office – ICO):
- The nature, scope, context and purposes of the processing
- Assess necessity, proportionality and compliance measures;
- Identify and assess risks to individuals; and
- identify any additional measures to mitigate those risks.
The DPIA should be reviewed and controlled under a formal data governance process, as it represent a key project artefact thus any early draft should provide greater value to the DPO.
Article 38 of the GDPR provides that the controller and the processor shall ensure that the DPO is ‘involved, properly and in a timely manner, in all issues which relate to the protection of personal data’
Reinforce the obligations for Data Protection
The DPO must ensure that:
- All members of staff are fully conversant with their obligations under the GDPR.
- Data Privacy across the organisation is promoted via training, internal social media, intranets or any other means.
- Staff are aware that any data subject requests are actioned immediately and the DPO is notified.
The DPO should be considered as a trusted impartial advisor to the organisation, one who will instil best practices and confidence both internally and externally of the organisation.
The DPO should as a trusted advisor consider the following:
Organisational Information / System Processes
Understanding the data lifecycle i.e. how data is captured (the channels), permissions, how the data is processed, transformed, retained and used is fundamental to ensuring that information integrity is maintained. Something which must be understood by the DPO to ensure he/she can answer any requests or queries that may emerge.
During any project or programme of work, the Data Protection Impact Assessment (DPIA) process will help identify and minimise the data protection risks of a project or programme of work.
Technically, it would be prudent to understand the system processes and the associated production systems to ensure that any ‘data touch points’ are fully understood or at least documented/audited regularly.
The DPO must have an understanding of organisational culture (ways of working), the market it operates, and its operational practices to ensure that the best processes regarding data management and data rendering are maintained.
Whilst this may be documented, I would strongly recommend the DPO occasionally undertakes a ‘sitting with Nel’ exercise to perform random checks to ensure he/she is comfortable with actual data processing policy enforcement.
The DPO should be familiar with all Data Capture Channels, layers of the Enterprise Technology Landscape and data air gaps that may be prevalent and advise on possible attack vectors in order to pre-empt any possible breaches of data privacy.
To ensure consistency between the DPO and the data controller or processors all decision-making with regards to requests or DPIA outcomes must be documented, including any difference of opinion that may arise during the governance meetings.
Organisation Information Patterns
During his tenure as a DPO the individual should add value by highlighting common patterns observed and more important the remediation actions for the controllers to introduce.
A DPO is in a favourable position as he/she can step back and highlight common reoccurring patterns that may be missed by the data controllers/processors.
Central Point of Contact for the Supervisory Authority
The DPO is the primary point of contact for the ICO i.e. the Information Regulator and more importantly also the primary point of contact for all Data Subjects (Employees, Business Partners and Customers).
Any communication between the DPO and the ISO must be documented and relayed to senior management of the organisation in a timely fashion.
Central Point for Data Subjects
The DPO is the primary point of contact for any Data Subject Requests, be they Employees, Business Partners and Customers or any third party that the organisation may hold information on.
This is a crucial element of his/her duties – any subject access request should be managed promptly and communication by the DPO and the Data subject must be rapid and prompt.
How does one perform the duty of the DPO? This is a topic of great interest for me, as I see it as not simply the chairing of meetings or review of artefacts. Suggestions on a post card please 😊
Realisation of the service of a DPO, after all it is a service that can only be achieved if he/she is a critical part of the Data Governance Process and in many cases serves as the gatekeeper on some projects.
The DPO should chair monthly schedule meetings to ensure that any requests are put into motion and tracked but also as a background process validate these actions.
The DPO must be alerted to and be notified to inform and manage stakeholders immediately in the event of any breaches and ensure that all immediate risks are mitigated .
The DPO is a ‘Service Provider’ in terms of managing the organisational obligations under GDPR and as such should also be subject to performance metrics where possible ?
The role of the DPO is well documented, this blog just provides some additional thoughts to my previous blog from 2017.
Over the past decade working with security professionals I have become concerned that they, especially in the government sector, focus on ‘process’ and not the real threat vectors. GDPR moved the goal post from the previous Data Protection Act in favour of empowered data subjects – which is a good thing.
I truly hope that the DPIA process does not become a ‘tick in the box exercise’ and organisations do not forget that attacks to their technology landscape can come from a plethora of different sources and thus place adequate proactive measures to mitigate any possible attacks resulting in data breaches.
A must read if you are interested in the role of the DPO is the
Whilst my blog is short – it should provide some insight into the role of a DPO and to be honest there is enough material out there and I didn’t want to reinvent the wheel – so sharing some basic thoughts as always happy to take feedback but not enter into an online debate.
Recently I posted on Linkedin some late-night notes for a project I am currently working on – I was not expecting any comments or even any views, so I was pleasantly surprised when I saw the number of views ! . So, I thought why not extend, produce a picture view and share – so you can cut & paste and reuse, if you so wish.
- Define the Problem or the Situation you wish to address
- Gather relevant Data / Information
- Separate Certainties from Uncertainties
- Develop Scenarios / Use Cases
- Define a baseline criterion with some weightings
- Use Scenarios in your What-If planning
- Score Results / Outcomes
- Calculate Risk – Apply leavers to minimise any exposure to debt (technical, personal, organisational, reputational)
- Define and assign possible Key Performance Indicators (KPI’s)
- Implement plan
- (Big Bang or Phased)
- Measure where possible
- Adjust and Fine Tune your thinking.
- Analyse the end state
- Recalibrate if/where required.
Note: The Flow represents from Problem to Realisation and does not factor in any context to the problem i.e. the external or Internal factors that would influence the pre-problem conditions / events.
Hope it’s of use.
During my workshop on the 17th July at the BCS EA Conference in London, I presented an A0 sized picture representing a further decomposition of the next level of the stack (without links between the layers).
The reason I like doing these sessions is the interaction where the particpants bring a different perspective.
Following on from the session I modified some of the wording e.g. no longer Applications , but now Execution Service and I included PEST at the Business Operating Model layer.
If you do re-use picture please quote the source!
Last Month I was asked to do a Webinar for the Australia Computer Society (ACS) – Queensland.
The URL to the YouTube Video for my session is : https://youtu.be/_41-izCm5rw
I discus some methods / question that the EA should consider and present the following picture, I would recommend skipping the first 7 minutes and 30 seconds.
The two-part webinar had a primary focus on Enterprise Systems Architecture with a discussion on a notional architectural stack, some of the artefacts and a brief discussion on the role of an EA / SA from my experience.
During the webinar I presented some methods / questions for EA awareness around the stack and I used the following picture which took me ages to think about and produce , so I thought I would share on the blog.
The vidoe for the session is : https://youtu.be/_41-izCm5rw
With the BA IT Systems Failure over the weekend and the GMB union saying that the meltdown could have been avoided if BA hadn’t made hundreds of IT staff redundant and outsourced their jobs to India at the end of last year, I thought I would post a mind map I created and used to structure an Inspection I recently undertook.
My Inspection was undertaken in abroad for a UK client who had outsourced the management of its UK Data Centres and IT Systems to a Indian supplier.
If the above was the root cause of the problems at BA , then I am happy for the managers at BA to contact me and borrow the format for a full audit which they must conduct.
It must be noted that my focus was on the management of the technology estate and not so much on the Contract.
Note: If this posting gets enough views over a given period – I may do a blog post on the methodology and approach I followed during the one week audit in country (obviously I will anonymise the client and supplier details)
Recently I posted a work in progress picture on Linkedin on the Solution Architecture Lifecycle – with a 1000+ views, I thought I would post a more detailed picture on my blog accompanied with some very brief notes.
Solution Architects as previously mentioned are responsible for working with programmes and projects to ensure a solution to problems is designed, costed, procured, built and delivered into the organisations which often results in delivering a new process outcome and IT capability.
Solution Architects address a wide spectrum of problems and issues ranging from the simple to the complex and thus require a wide range of skills (technical / business).
The work of the Solution Architect can be broken down into distinct stages and categorised into the following areas:
Each layer of the Solution Architect Lifecycle is briefly discussed below. However, it must be noted that the focus at each layer will be aligned to the top layer i.e. the problem/issue.
Often a problem requires a working group to establish if something is worth considering e.g. bid on a project or to discuss a ‘pattern’ that is emerging in the technology landscape which requires investigation from the reporting systems e.g. Capacity & Performance / Security incidents.
Solution Architects are often engaged at this stage to provide advice on possible options for resolving a problem and to assist in triggering the next phase of the activity.
Defining the context of the problem/issue
No project or programme of work in real terms commences without a Business Case i.e. a document that captures the reasoning for initiating a project or task with basic costings and outcomes documented. If the problem issue is a Technical one then the Solution Architect is required to elaborate (in simplistic terms) the context of the problem from the systems viewpoint.
Capturing the Requirements
During the requirements capture phase the Solution Architect will spend much of his/her time focusing on the system elements of the requirements and trying to understand the system components characteristics.
During this stage, there will be a bias towards the non-functional elements of the system.
During this stage, a Minimum Viable Product can be elicited from stakeholders, i.e. the minimum components and effort that will be required to deliver the functional and non-functional requirements can be sketched to define further costs analysis.
It must be noted that the requirements must also encapsulate any legal compliance issues e.g. GDPR requirement and any Enterprise Architectural directives.
Defining Product Backlog and or Level 0 Systems Architecture
Once the problem is known, documented and decomposed into a set of clearly defined functional and non-functional requirements a level 0 systems architecture can be produced to outline a solution.
Where possible reusable components should be highlighted to shorten time to market and increase savings to the project.
At this stage, the outcome should be a level 0 design and in many cases, result in a product backlog for the solution
The level 0 design will facilitate the project to determine the cost and effort involved to deliver the outcome required.
Designing the Solution and breaking down the deliverables into sprints
At this stage, a detailed analysis of the Level 0 is undertaken and elaborated further to deliver a detailed design document and the subsequent technical sprints to deliver the project.
Depending on the Solution it may be prudent to produce a low-level design to support the Solution Design.
Options for realising the solution and enacting
I have discussed previously the options that are available for analysis from “do nothing” to “Build” but from a cost / do ability view the option should be selected that leverages existing relationships /services and best value for money.
Delivering Solution into production
Developing, procuring or modifying a system requires deployment into a production environment and thus the Solution Architect must be capable of defining the environments (test, prod, pre-prod) for the route to live. Often this will involve working with the Service Architects to design the Service and the operational elements (often extrapolated from the NFRs) of the system.
If we were to take all the elements above and assign time that the Solution Architect would be involved in the project then we could produce a graph like the one below;
In summary, the Solution Architect is an important role and requires skills that evolve with each engagement and has a role to play from problem realisation to delivery into service of a solution.
Recently at the London Metropolitan University, hosted by the students Union, I presented an example in which the introduction of new legislation would impact my version of the Enterprise Architectural Stack.
Subsequently after reading all 80+ pages of the General Data Protection Regulation (GDPR) I thought I would blog additional information and playback what I highlighted during the presentation, as I consider this an important game changing piece of legislation for those of us in Europe who design, deliver and manage Enterprise Systems.
This blog is split into two parts –part 1 focuses on GDPR and the importance of the what and the why, whilst part 2 focuses on the how i.e. how GDPR will Impact the Technology landscape of most organisations together with some potentially impacted areas.
Part 1 – Brief Overview of the GDPR
The text of the GDPR was agreed at the end of 2015 and will be applied in the UK from 25 May 2018. The government has confirmed that the UK’s decision to leave the EU(Brexit) will not affect the commencement of the GDPR which will replace the Data Protection Act 1998.
The EU version will be implemented with increased levels of fines for non-compliance (up to 4% of annual global turnover or 20m Euros, whichever is greater) and raises a lot of questions as to how it will be implemented in terms of associated controls and measures for organisations.
The legislation will enforce a large number of changes and organisations will need to consider it carefully and make sure they are compliant by the time it comes into force in 2018 addressing Issues such as consent, increased administrative requirements and the need to provide a full audit trail, data exports and the new obligations.
Full text of GDPR can be found at : http://ec.europa.eu/justice/data-protection/reform/files/regulation_oj_en.pdf
The Table below summarises key headlines from the GDPR, if however you require further information I would recommend visiting http://www.eugdpr.org/eugdpr.org.html
|GDPR applies to non-EU organisations offering goods or services to data subjects in the EU or monitoring to the extent to which the behaviour takes place in the EU.|
|There is no requirement to notify authorities of data processing but a requirement to keep records of data processing activities (subject to limited exceptions for SMEs).|
One Stop Shop
|Organisations will be regulated by a single regulator in the place of their main establishment.
Individuals will be able to make complaints in their Member State at which point that regulator will engage in a cooperation procedure which will be settled by the European Data Protection Board in the event of disagreement.
|GDPR significantly raises the stakes in terms of compliance, with maximum penalties of 4% annual global turnover or up to 20m Euros (whichever is higher).|
Data Protection Officers
|There is a requirement to appoint a data protection officer (DPO) where an organisation’s core business involves processing personal data involving regular and systematic monitoring of data subjects or large amounts of sensitive personal data.|
|Breaches must be reported to the relevant regulator without undue delay and where feasible, within 72 hours of becoming aware of it unless the breach is unlikely to result in a risk to the rights and freedoms of individuals.
Data Subjects must be informed without undue delay where the breach is likely to result in a high risk to the data subject’s rights and freedoms unless the data has been rendered unintelligible to any third party, the data controller has taken steps to ensure the high risk is unlikely to materialise.
Data processors are required to inform Data Controllers of any breach.
|Organisations relying on consent to process personal data will need to show that the consent is freely given, specific and informed and is an “unambiguous indication” of a data subject’s wishes and expressed either by a statement or a clear affirmative action.|
Data Protection Impact Assessments
|Organisations will be required to carry out data protection impact assessments (DPIAs) if their proposed activities are likely to result in a high risk for the rights and freedoms of individuals, in particular, through the use of new technologies and in cases of people profiling. If the DPIA reveals a significant risk, organisations must consult with their regulator before beginning the processing.|
Data subject rights
|GDPR contains new rights around data portability, the right to be forgotten and to prevent profiling. It also continues the right to object to processing, to rectification and erasure.|
Privacy by design and default
|Something most Information Assurance Consultants have been promoting for years in that controllers are specifically prevented from setting defaults to disclose data to all in both systems and business processes.|
|Data processing must be carried out for the original purpose(s) for which it was collected unless the new purpose is a compatible one.|
Data export to third countries
|There are similar restrictions on transfers of personal data outside the EU in the GDPR as under current law. Data can be transferred under a Commission adequacy decision (the GDPR contains details of how these should be reached).
In addition, there are limited possibilities to transfer data with consent or where it is necessary for the performance of a contract.
|GDPR will apply directly to data processors that will be subject to compliance requirements and to sanctions for non-compliance in part.|
Subject Access Requests
|Individuals can make subject access requests (SARs) to find out details of information held about them and how it is used. SARs must be responded to by the data controller without undue delay and, at the latest, within one month of receipt of the request. This period may be extended for a maximum of two additional months when necessary, taking into account the complexity of the request and the number of requests. The data controller has the right to charge a reasonable fee to cover administrative costs but only where the requests are “manifestly unfounded or excessive”. The controller can also refuse to respond under these circumstances.|
Digital consent for minors
|While the default age for giving valid consent and using online services is set at 16, Member States will be able to reduce this to as low as 13.|
Part 2 – GDPR Impact on the Technology Landscape?
GDPR as shown in Part 1 will have a major impact on the way organisations collect, process, transform, store, present and consume information. This impact can be mapped to my notional Enterprise Architectural Stack at every layer.
The diagram below highlights the mapping, impact areas are shaded in black, and will require consideration, effort and in many cases recalibration of legacy systems to meet the legislative requirement. Each impacted area is discussed briefly further below;
Business Operating Model
The biggest driver for change could be considered the potential fines that the organisation may be subject to for non-compliance and these influence the Business Model of Operation.
The appointment or nomination of an Organisation Data Protection Officer (DPO), a standard function in many government agencies and departments will now have to be replicated in the non-government sectors.
Consideration will also need to be given to methods and techniques for presenting, pulling, consuming and pushing information in and out of the organisation.
The adjusted Business Operating Model will require process support as Business Process will be hit hard as existing programmes / projects inflight will need to be recalibrated to meet the requirements of GDPR.
Additional Management and Reporting of GDPR is inevitable and organisations will need to re-evaluate existing business and technical process (triggers, execution methods, data sets) for reporting. This analysis will result in the introduction or refinement of additional processes some of which, but not limited to, are processes to support;
- The Management of subject access requests (SARs)
- Complaints receipt and handling
- Notifications (received and sent) to Data Subjects
- Information retention (audit/traceability)
- Governance of Data
- The DPO in their duties.
The channels of data exchange between the Enterprise and Data Subjects will all require review and in many cases updating, as this is the point at which the Subject provides his/her data to the Enterprise.
Organisations may be required to develop new system and business capabilities and in many cases provision new services which support internal and external information exchange requirements.
Example of impacted or potential new services are;
- Services that facilitate Privacy as default as a Macro or Micro Service.
- Possible notification Services (SARs etc)
- Extension of Reporting Services – this is given !
- Revaluation of Channels for information dissemination – Pervasive Devices, Web Portals etc
Existing Applications that interact with Users and in many cases capture information will require evaluation to ensure that “consent is freely given” for the use of this information.
In cases where the application is a Commercial off-the-shelf package then this requirement can easily be pushed back to the vendor/supplier. However if the application is in-house or 3rd party developed custom development this may require refactoring.
Applications that Extract, Transform and Push or Pull Subject Data to any 3rd party System internal or external to the Organisation will require analysis and in many cases flagged for recalibration to ensure it remains compliant with GDPR.
Data and Information
The General Data Protection Regulation is a data-centric policy and therefore will impact the way information is collected, transformed, shared and persisted both internally and externally of the organisation.
Analysis of existing stores and custodians of the stores will require analysis, especially as full transparency must be shown on who has access rights to the data and how those access rights are controlled
It must be noted the Organisational DPO may require new Reporting Data Stores to enable them to perform their duties in terms of analysis and regulatory reporting.
Any data which is transferred outside of the organisation and outside of the country of operation will require closer scrutiny.
Data and Information Insights will need to be developed to ensure that compliance is not only met but be shown to be met down to data objects in physical databases.
Most Technology Services i.e. the enablers will require semi-analysis as there may be a need to analyse how the information flows are orchestrated, both in and out of these domains, examples are
- Messaging Systems – end points will require analysis.
- Logging Systems – these will need to be analysed to see if User information is persisted and if not animalised then how the information is used.
- If an Enterprise Service Bus(ESB) is used – how if any user data is transformed during its journey through the bus and attached systems.
- Reporting Engines – How are these leveraged and can they be reused?
Disaster Recover System
Most Organisations have a Disaster Recovery (DR) capability, which may be placed on standby (hot or cold) – these stand by systems may hold information which is synchronised at frequent intervals to ensure that if a system crashed they can be recovered to the specific point and within a specified time.
These systems will retain data – if these systems are not a true replica of live then this may require analysis in terms of the retention of User data.
One of the requirements of GDPR is the production of Data Protection Impact Assessments or DPIAs – One can argue UK Government Security Officers produce similar information in the form of Risk Management & Accreditation Document Set (RMADS) for secure accredited systems.
RMADS for Government functions may encapsulate much of what is required in the DPIAs if applied to the Government Sector a similar set of documents will need to be adopted by Security or Information Assurance functions in the Commercial Sector.
The General Data Protection Regulation (GDPR) is around the corner and organisations must be in a state of readiness now! I would strongly recommend all Enterprise and Solution Architects to ensure that they are fully aware of the act and their duties in relation to designing, building and supporting enterprise systems.
I have only touched on some macro level issues that need to be addressed, it is when one deep dives into each layer of the stack, within an organisation, can one see there is a tremendous amount of effort required to ensure compliance or mitigate the risk being fined.