Home » 2017
Yearly Archives: 2017
A path from Problem to Realisation
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.
oOo
Enterprise Systems Architecture Stack Update
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!
oOo
Webinar
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
oOo
Inspection of an Outsourced Service Provider (Mind Map)
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)
oOo
The Solution Architecture Life Cycle
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:
Solution Architecture Life Cycle
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.
Identification
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.
General Data Protection Regulation (GDPR) and the Enterprise Technology Landscape
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
|
Territorial scope |
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. |
|
Notification |
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. |
|
Penalties |
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. |
| Breach Reporting
|
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. |
|
Consent |
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. |
|
Purpose limitation |
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. |
|
Data Processors |
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.
Business processes
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.
Capabilities Services
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
Applications
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.
Technology Services
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?
Hygiene Services
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.
Security
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.
Final Note
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.
Thoughts from the Systems front line.... 