Better architecting with - explicit #security

1 Addressing crosscutting aspects by-design

Various crosscutting aspects (also known as non-functional or quality characteristics) of systems are, actually, dependant on all the system elements and relationships between them. For example, the security design principle “weakest link” is saying that “in designing security for a system, focus should be put on the weakest components of the overall system” (see Goldratt E.M., Cox J. The Goal: A Process of Ongoing Improvement, Second Revised Edition, 1992).

The understanding of emergent nature of crosscutting aspects led to raising of requirements for addressing them “by-design”. The most noticeable example of “privacy by-design” is the General Data Protection Regulations (GDPR) from the European Union (see https://eur-lex.europa.eu/eli/reg/2016/679/oj ). The concept “a system characteristic by-design” may be defined as “taking into account the characteristic throughout the system entire lifecycle processes (e.g. architecting, engineering, construction, operating, etc.) as an essential emergent characteristic of the system”.

2 Security Risk Architecture Model (SRAM)

To “estimate” a relative value of a non-functional or quality characteristic of a system at any stage of the system life cycle, it is necessary to “spread” such characteristic over the system elements and relationships between them. Figure below shows, that by knowing:

1. the security-related paraments, i.e. threats, attacks and vulnerabilities (see oval “Security”) for each least granular system elements;
2. relationships between the system elements (see oval “Architecture”), i.e.
   • how a set of least granular elements forms a service,
   • how services are used in business processes,
   • how business processes contribute into results,
   • how results reflect goals,
   • how goals are important for the system;
3. adverse impact which is produced by problems with each system element;

it is possible to objectively evaluate system risks (see oval “Risk management”).

Considering that relationships between system elements are static or dynamic then the structure and behaviour of security will be covered. The same can be done for all crosscutting aspects: security, privacy, safety, reliability, resilience, performance, value, income, expenses and other emergent characteristics.

3 Enhancement practices

There are internal and external enhancement practices for each crosscutting aspect. The internal enhancements practices comprise various certifications and industry agreements which are aspect-specific and element-specific. The external enhancement practices depend on the treatment of an element as:

• “white-box” with fully internal visibility and testability – some simulation, inspection and compliance external enhancement methods can be used;
• “black-box” with no internal visibility and testability – use external enhancement points for data/information inputs and outputs, and external enhancement controls for leaks detection;
• “grey-box” with partial internal visibility and testability – combining two previous options.

Typically, external enhancement methods are based on explicit relationships between elements (e.g. information flows). External enhancement points are based on digital archives and technologies similar to Security Information and Event Management (SIEM) tools. External enhancement controls are monitoring tools with some AI logic, for example, Data Loss Protection (DLP) tools.

For each relationship between elements, use external enhancement points for data/information flow starts and ends, and external enhancement controls for data/information transit.

The static relationships are expressed by any structural connection between elements, but dynamic relationships are expressed only by events (ECA and EPN techniques), processes (BPM techniques) and information flows (IFD techniques).

For example, a process model formally identifies all necessary enterprise enhancement points, methods and controls. (see figure below)

1. Add all external enhancement points.
2. Add all external enhancement controls for 4 activities which are “black-boxes”.
3. Add all external enhancement methods for 2 activities which are “white-boxes” and the process as the whole.
4. Add all the events and mitigation processes for some of them.

Thus, an explicit description of system elements and relationships between them provides a nomenclature of external enhancement practices, controls, points, and methods to be added to the system. Then they have to be linked to the risk management practices. All the information risk-related information sourced from various crosscutting aspects must be collected and treated together (see figure below).

1. Enterprise business functions should be enriched to generate the risk-related information.
2. Those risk-related data need to be collected at the enterprise data warehouse together with other business information.
3. Some business processes need to be updated to embed risk-related activities.
4. A set of risk-related rules, logic and risk-related knowledge should be able to use the risk-related and other business data to detect acceptable limits of risk as well as interdependencies and correlations between different risks.
5. Some business processes for risk mitigation maybe automatically activated.
6. A lot of risk-related indicators, alerts should be available in the form of dashboards and reports available for different staff members.
7. Staff members should be able to initiate business processes based on the observed risk-related information.

Additional security-related techniques are mentioned in https://improving-bpm-systems.blogspot.com/2014/04/ideas-for-bpmshift-delenda-est-vendor.html

4 Conclusion

Crosscutting aspects are desired emergent characteristics of a system. They must be addressed systemically.

Thanks,

AS


This blogpost belongs to the series https://improving-bpm-systems.blogspot.com/search/label/%23BAW

Better architecting with - solution artefacts

1 Introduction

Although the global success of software is unquestionable (“software is eating the world”, everyone wants to use agile, etc.), last year the agile guru and “father” of microservices Martin Fowler was talking "why are we struggling" (see https://martinfowler.com/articles/agile-aus-2018.html ). He pointed at three problems:

1. Get rid of the Agile Industrial Complex and the idea of imposing stuff on teams. Let teams work out the way they should work themselves.
2. Raise the importance of technical excellence, and never forget that when writing software, the technology side is really vital, and
3. Organize around products.

Let us see how architecture addresses these three points (please, note that the word “architecture” has not been used in this speech).

The point 1 is actually well-known for architecture – no organisation is using only one framework and a framework “as is”. It is always a mixture of several frameworks which have been “massaged” to handle the real and unique needs of an organisation. To overcome this problem, the serious of blogs “Better Architecting With” (BAW) https://improving-bpm-systems.blogspot.com/search/label/%23BAW introduces a different approach – architecture description (remember ISO/IEC/IEEE 42010) which is a set of views and models, these models are aligned, and some models are, also, parts of system-of-interest. Thus teams may use views and models as they want.

There is already a standard set of model-types (e.g. I use 100+ of them) and there are some methods to generate (sometimes semi-automatic) some models from existing models. Processes are not fixed, but there is a natural order of dependencies between model-types. So, the teams may have a lot of freedom by using standard methods and model-types.

The item 3 is also well-known for architecture – the entity (product, solution, system, etc.) life cycle is more important than projects at various stages of such life cycle (see https://improving-bpm-systems.blogspot.com/2018/01/better-architecting-with-explicit.html ). So, there is a clear separation of duties:

• Use architecture to define the units-of-work to be done and some dependencies between them.
• Use agile to schedule and monitor execution of such units-of-work.

The item 2 is, actually, about being able to build that kind of adaptive software including refactoring – ‘I always loved Mary Poppendieck's phrase, "A late change in requirements is a competitive advantage." But to do that you need software that's designed in a way that's able to react to that kind of change. Refactoring is central to this because refactoring is a disciplined way of making changes.’

It seems that the guru is “self-locked” in the software domain in accordance with the well-known observation “if all you have is a hammer than everything looks like a nail”. Software has its artefacts (classes, packages, interfaces, schemas, services, applications, platforms, etc.), however solutions are, also, built from a different set of artefacts (which use software artefacts, of course). 

2 Solution artefacts

Architecturally, solutions consist of solution artefacts such as:

• events,
• processes,
• UI forms,
• roles,
• rules,
• KPIs,
• audit-trails,
• reports,
• automation scripts,
• data structures,
• documents,
• IoT devices,
• etc.

Also, architecturally, each of these artefacts may have several facets:

• specific management tool, e.g. Business Process Management (BPM)-suite tool;
• templates, e.g. process templates;
• instances, e.g. process instances;
• APIs (or interfaces) to all functionality, and
• patterns used by templates, e.g. workflow patterns.

Obviously, the specific management tools for these solution artefacts are needed only once for all the solutions within the whole computing environment, i.e. enterprise-wide. Also, templates, patterns and APIs are shared between many solutions. So, each unit-of-functionality that is used by more than one solution must be put aside and organised for sharing.

Logically, all the units-of-functionality to be shared should form an enterprise-wide platform (this is a type of software artefacts) and some units-of-functionality may become microservices (this is a type of software artefacts). 

3 Platforms and microservices orientation

The logic behind platforms is rather straightforward – instead of developing traditional applications which contain a lot of duplicating functionally, all common functionality is collected into a platform and solutions which are built on top of that platform possess only unique functionality. See figure below.

Planform is designed on the following principles:

• The platform simplifies the use of its platform components and ensures interaction between them. Thus, the platform frees up resources to focus on solving unique problems.
• New solutions are implemented outside the platform using rapid development techniques (agile methodology) and platform existing functionality.
• The planning of new solutions is coordinated within the scope of the platform to minimize duplication of efforts in solving the same problems.
• Successful new (thus innovative) solutions are gradually included in the platform for their wide use.
• Constant improvement of the platform is achieved through transparency, feedback, results of use and systematic evaluation of existing platform components.
• All interactions inside and outside the platform use the standardized interfaces (API methodology).
• The platform provides for several interchangeable options for some platform components.
• The platform offers not only a rich functionality, but also a methodology for developing various solutions based on it.
• The platform is built gradually by increasing its functionality horizontally and vertically.

The platform-enabled agile solutions orientation implies common engineering practices for solutions created on top of the platform. Any solution which is built on such a platform must contain only functionality which is not implemented in the platform (see Figure below).

4 Smart cities reference architecture case

Let us illustrate platforms, solutions and solution artefacts with the Smart Cities Reference Architecture Methodology which is under development in the IEC System Committee “Smart Cities”. Some of the goals of this methodology are to guarantee that 

1. all the common functionality is developed once and used by many Smart Cities and
2. individual Smart City can easily developed their own unique solutions (including replacing some platform functionality).

The analysis of Smart Cities functionality demonstrated that minimum 3 platforms are necessary: universal, urban-generic and urban-specific (see Figure below).

Another option is to split the urban-specific platform into 14 platforms.

To facilitate the isolation of solution artefacts, a reference application architecture for solutions is proposed (see figure below).

Then all the various facets (tools, APIs, patterns, templates and instances) are mapped to the platforms and solutions (see figure below).

5 Typology of solutions

The reference application architecture for solutions can be further elaborated by adding a typology (classification) of solutions. This means that there are some types of solution and each type is formed around a predominant solution artefact, namely:

• event centric,
• data-entry centric,
• document/content centric,
• data or/and information flow centric,
• data or/and information visualisation,
• IoT-device centric,
• short-running operations (or activity-based),
• long-running operations (or process-based),
• etc.

For each of these types of solution it is possible to propose a reference architecture. For example, a process-based solution reference architecture is illustrated in figure below. (Note that each activity in this process is surrounded by microservices with pre- and post-automation strips.)

However, a real solution, usually, combines some of those types.

Thus, solutions are delivered in accordance with the following generis procedure:

1. Minimal architecting to understand the type (or a mixture of types) of a solution.
2. Collecting use cases to define capabilities of the solution.
3. Quick prototyping to outline functions, APIs, and solutions artefacts.
4. Conducting gap analysis to determine what is missing in the platform(s).
5. Developing missing functionality as microservices to close the gap.
6. Assembling newly created and existing microservices to deliver the solution.

And, don’t forget the versioning for everything.

Thanks,
AS

This blogpost belongs to the series https://improving-bpm-systems.blogspot.com/search/label/%23BAW