Smart Cities from the systems point of view

Thanks,
AS

Better Architecting With – big picture

This blogpost continues the blogpost “#entarch frameworks are typical monoliths which have to be disassembled for better architecting” ( see http://improving-bpm-systems.blogspot.bg/2017/06/entarch-frameworks-are-typical.html ) and uses some feedback from a LinkedIn discussion https://www.linkedin.com/feed/update/urn:li:activity:6278239461654437888/

This blogpost outlines a “big picture” including the components and operating model for Better Architecting With (BAW).

Again, the goals of BAW are:

• to standardise a good set of #entarch common components (viewpoints, artefacts, models, etc.)
• to enable the users to add their own components, if necessary
• to provide formal and repeatable guidance how to achieve unique user’s needs with available components.

BAW follows the “Platform-Enables Agile Solutions” (PEAS) pattern ( see http://improving-bpm-systems.blogspot.bg/2011/04/enterprise-patterns-peas.html ). BAW comprises the following:

1. BAW platform;
2. a set of ready-to-use popular BAW solutions (consider them as recipes) which you may try as-is and gradually adapt for your unique needs, and
3. BAW guidance (including some obvious documentation).

The BAW platform comprises the following components:

• BAW ontology – a set of about 200 concepts (in my estimation) which are already defined in many sources and needed to be aligned.
• BAW artefacts – a set of about 50 (in my estimation) well-known artefacts to be aligned.
• BAW viewpoints – a user-extendable set of about 20-30 (for now) viewpoints.
• BAW model kinds – a user-extendable set of about 50-70 (for now) model kinds.
• BAW patterns – a user-extendable set of techniques for transforming (not necessary fully automatically) some model kinds into other models kinds.

The most innovative part of the BAW platform is the BAW patterns because they capture architecting knowledge in a formal and reproducible way. BAW patterns are formalised as small processes with human and automated activities. Some example of such patterns are in http://improving-bpm-systems.blogspot.bg/search/label/enterprise%20patterns

The BAW solutions comprise the following:

• BAW scenarios – a set of popular architectural works such as designing data-entry application or process-based applications, defining business architecture, formulating IT strategy, etc.
• BAW skeletons – a set of existing #entarch frameworks

The BAW guidance is the most important part of BAW. In accordance with the selected scenario, the user is guided what views and models must be developed and how to develop them. The order of development can be almost arbitrary because the user must be able to adjust his/her models in the “pinball” way.

Again, the whole BAW must be organised in a way that anyone can add new viewpoints, model kinds, patterns and related documentation to enrich BAW with formalised and repeatable knowledge.

Thanks,
AS

#entarch frameworks are typical monoliths which have to be disassembled for better architecting

This blogpost starts the "Better Architecting With" series http://improving-bpm-systems.blogspot.bg/search/label/%23BAW

#entarch frameworks are considered as a must for any serious #entarch work. There are about 1 000 #entarch frameworks on this planet. The most popular of them are typical monoliths – huge in size, contain a lot of overlaps, slow to evolve, difficult to adapt to particular needs, expensive to learn, tricky to explain, etc.

Not surprising that some organisations have to use a mixture of #entarch frameworks although some #entarch frameworks allow some tailoring. For example, an organisation has to use FEA because they work with the local government, TOGAF for solutions and ZF as a foundation.

Considering that organisations are demolishing/modernizing/transforming their application monoliths, let us, enterprise architects, apply the same tendency to #entarch frameworks. Such a transformation must:

1. preserve and externalise (from the monolith frameworks) the knowledge which is accumulated by those #entarch frameworks, and
2. provide a guidance how to build and operationalize unique #entarch practices from a coherent set of repeatable (proven or innovative) #entarch techniques and methodologies.

De facto, the “erosion” of the monolith nature of #entarch frameworks is already ongoing (examples, Tom Graves work).

Let us outline the target way of architecting:

• Commonly-agreed terminology. Example - http://improving-bpm-systems.blogspot.bg/2015/10/concepts-crisis-in-it-and-sister-domains.html
• A set of viewpoints, model kinds and artefacts. Tey have to be properly described. Example – see slides 7-28 from http://improving-bpm-systems.blogspot.bg/2015/10/concepts-crisis-in-it-and-sister-domains.html
• Set of repeatable techniques and methodologies. This is the key point – a lot of patterns and algorithms must be available to various views, models and artefacts. Ideally, a change in some models should be easily propagated to linked downstream models. Example – IT strategy, some of the enterprise patterns, see http://improving-bpm-systems.blogspot.bg/search/label/enterprise%20patterns
• A configurator to define which viewpoints and models kids are required in a particular case. It may be manual at the beginning. 
• A guide how to explain different viewpoints and model kinds to all various stakeholders.

The process of architecting will be as the following:

• use the configurator to describe the problem space and generate a set of viewpoints for the solution space
• use techniques and methods to specify an initial set of models
• obtain OK from all the stakeholders
• use techniques and methods to specify all the rest models

Again, the key point is a set of techniques and methodologies to link models. Repeatable techniques and methodologies will lead to better #entarch tools and high level of automation. The whole architecting process will be faster, better and cheaper.

Thanks,
AS

#GDPR as an #BPM application

This blogpost explains how to implement the EU General Data Protection Regulation (GDPR) by design and by default via Business Process Management (BPM). This blogpost describes only a reference solution architecture without much implementation details. It focuses, primarily, on the artefacts such as capabilities, rules, roles, data-structures, documents, explicit coordination and audit trails.

1 Terminology in the GDPR

Although the information security domain is developed well, the GDPR document (see article 3) uses rather exotic terminology (sources are not provided). For example, many concepts, available from the standard privacy framework (ISO/IEC 29100) have different designations (terms). Another example is that the concepts “data” and “information” do not follow the DIKW “pyramid”.

Although a mapping between 16 terms of the GDPR and existing terminology is not difficult, it would be better to avoid such a mapping.

2 The main element

The main element of the GDPR is a data-structure object “Personally Identifiable Information” (PII) in the ISO/IEC 29100 terminology or “personal data” in the GDPR terminology. It must be explicitly and carefully protected:

• for its confidentiality, integrity and availability
• in rest, in transit and in use
• throughout its life cycle

Usually, the life cycle of PII objects is very simple and covered by 4 actions which are known as the CRUD pattern (although each update may create a new version of the PII object). 

3 The core processes

Those actions, namely, Create, Read, Update and Delete, must be presented as small processes (or workflows) to provide the design and execution traceability. Considering that any PII is owned by the “PII principal” (or a natural person to whom a set of personally identifiable information relates), he/she must approve some actions on his/her PII object.

For example, an PII principal must provide his/her consent to process his/her PII object and such a consent must be kept as a record by the “PII processor” (privacy stakeholder that processes personally identifiable information on behalf of and in accordance with the instructions of a “PII controller”).

4 Some supporting capabilities

The core (or life cycle) processes use several capabilities (services or processes) such as:

• identity management
• access management
• anonymization 
• encryption
• etc.

Also, some error- and exception-handling processes are necessary to properly handle privacy incidents.

5 Related roles

The essential roles are the following:

• “PII principal” in the ISO/IEC 29100 terminology or “data subject” in the GDPR terminology – the owner of the PII, 
• “PII processor” – persons or organisations who/which execute the GDPR processes,
• “PII controller” – authority which, alone or jointly with others, determines the purposes and means of the processing of personal data, and
• “Data Protection Officer (DPO)” – person who is the owner of the GDPR processes.

6 Rules

The execution of the GDPR processes is guided by numerous rules which are; actually, the majority of the GDPR documents. For example, if a PPI principal is a citizen of an EU countries then “PII processes” must follow the GDPR.

Unfortunately, it is unknown if these rules comply to the MECE principle (no overlaps and no holes). 

7 Complex scenarios

There are a few scenarios which involve more than one PII object. For example, split, merge, export, transportation, correlation, etc.

8 Conclusion

Use of BPM to implement the GDPR addresses all the GDPR concerns. Explicit and machine-executable processes are mandatory to achieve by design and by default the listed below key points.

• Compliance – all privacy-related activities and coordination between them can be easy analysed.
• Accountability – generated audit trails provide factual and objective information about why did what.
• Data protection officers (DPOs) – as a role which owns all the GDPR processes.
• Consent – is achieved by the design of the GDPR processes and records management.
• Enhanced rights for individuals – is achieved by the design of the GDPR processes.
• Privacy policies – all PII controllers and PII processors must analyse their privacy policies via the logic of explicit processes.
• International transfers – also become processes.
• Breach notification – as an integral part of the privacy incident GDPR processes.

Thanks,
AS