Better architecting with - standard viewpoints and model-types

1 Smart Cities Reference Architecture Methodology

The IEC System Committee “Smart Cities” is mandated to develop the Smart Cities Reference Architecture (SCRA) which is a template for various Smart Cities solution architectures.  Although there are many reference architectures for Smart Cities, those architecture have been developed under different and unknown methodologies. This made practically impossible to use them together and to adjust them to the needs of a particular city system.

To address this problem the IEC System Committee “Smart Cities” had decided to develop Smart Cities Reference Architecture Methodology (SCRAM) as an international normative document IEC SRD 63188. The SCRAM provides the logic how to build the SCRA and how to tailor the SCRAM and SCRA. The ability to tailor is very critical.

• Cities, as places where people live and work, are very important for our civilisation.
• All cities are different.
• Smart City is a city which makes the world easier for citizen, society, business and government.
• In Smart Cities projects 50% – 70% of work is about IT, i.e. digital.
• Smart City is a city which is rebuilt as a digital system (Digital Transformation is critical).
• Digital systems can be done well, be adaptable and easy repeated (this is the main secret of Digital Transformation), but such emergent characteristics have to be purposefully created.
• If a common methodology for building Smart Cities as digital repeatable systems is used, then all Smart Cities are the 70% same (an estimation).
• Coordinated and cooperated building together Smart Cities as digital repeatable systems leads to substantial gains in cost, speed and quality of their implementations.
• An export version of the Smart Cities implementation is created automatically.

Considering that Smart Cities will be digital repeatable systems, it has been understood that a platform is necessary. The SCRA outlines the Common Smart Cities Digital Repeatable Platform. Because of the complexity in Smart Cities, this platform is actually a complex of platforms (See the illustration below, which is slightly different from the various version in https://improving-bpm-systems.blogspot.com/2019/03/better-architecting-with-solution.html). For each platform, the SCRA lists its own components and essential capabilities for each component.

To describe such complexity, the SCRAM provides 11 viewpoints and 107 model-kinds. Additional, the Smart Cities Implementation Manual is anticipated for continual improvement and collecting knowledge about the SCRAM and SCRA.

2 Example of tailoring

A country NNN decided to introduce a country-wide ICT reference architecture for all Smart Cities projects. The country wanted to reuse the SCRAM and SCRA for the NNN-ICT RA. There are two fundamental requirements:

1. The NNN-ICT RA must include communication infrastructure which is not defined in the SCRAM and SCRA.
2. The NNN-ICT RA must be detailed enough as a Reference solution architecture.

A recommended tailoring is below. For Reference architecture, consider the following:

• Describe the requirements for NNN-ICT RA by covering the SCRAM model-types 7.2-7.15; maybe in a free format.
• Outline NNN-ICT RA via the SCRAM model-types 7.16-7.30; use SCRA whenever possible.
• List of platforms to be provided at the beginning via the SCRAM model-type 7.43.
• Provide a view of the Universal platform via SCRAM PLATFORM ENGINEERING viewpoint (thus you will know components and solutions for this platform).
• Provide a view of the Urban Platform via the SCRAM PLATFORM ENGINEERING viewpoint (thus you will know components and solutions for this platform).
• Provide a view for each vertical platform, e.g. transportation, gas, water, energy, waste etc. via the SCRAM PLATFORM ENGINEERING viewpoint (thus you will know components and solutions for these platforms).
• For each SCRAM model-types 7.31-7.42 develop implementation materials, i.e. how different teams must provide various information, e.g. model processes, data, etc.
• Provide any additional views and models, especially for communication infrastructure.

For Reference solution architecture, consider the following:

• Provide view for the SCRAM CROSSCUTTING ASPECTS ENGINEERING viewpoint.
• Provide view for the SCRAM RISK MANAGEMENT viewpoint.
• Provide view for the SCRAM SOFTWARE FACTORY viewpoint.
• For each component of the Universal platform, provide a view via the SCRAM PLATFORM COMPONENT ENGINEERING viewpoint (start with 7.51-7.53).
• For each solution on top of the Universal Platform, provide a view via the SCRAM SOLUTION ENGINEERING viewpoint (start with 7.65-7.67).
• For each component of the Urban platform, provide a view via the SCRAM PLATFORM COMPONENT ENGINEERING viewpoint (start with 7.51-7.53).
• For each solution on top of the Urban platform, provide a view via the SCRAM SOLUTION ENGINEERING viewpoint (start with 7.65-7.67).
• For each component of the vertical platform, provide a view via the SCRAM PLATFORM COMPONENT ENGINEERING viewpoint (start with 7.51-7.53).
• For each solution on top of the vertical platforms, provide a view via the SCRAM SOLUTION ENGINEERING viewpoint (start with 7.65-7.67).
• Provide any additional views and models.

3 SCRAM viewpoints and model-kinds

3.1 VALUE viewpoint

The value viewpoint describes the problem space in terms of expected value for the stakeholders by providing some ideas about potential overall solutions (called system-solutions to distinguish them from solutions on top of a platform). The value viewpoint comprises the following model-types:

• Problem space overview (see 7.2)
• Problem space terminology (see 7.3)
• Problem space specifics nomenclature (see 7.4)
• Problem space classifications nomenclature (see 7.5)
• Stakeholders nomenclature (see 7.6)
• Stakeholders’ concerns nomenclature (see 7.7)
• Dependencies between generic system stakeholders, stakeholders, stakeholders’ concerns and categories of concerns (see 7.8)
• High-level requirements nomenclature (see 7.9)
• High-level stories nomenclature (see 7.10)
• High-level use cases nomenclature (see 7.11)
• Problem space coverage by the high-level use cases (see 7.12)
• The mission statement (see 7.13)
• The vision statement (see 7.14)
• The strategic goals nomenclature (see 7.15)

3.2 BIG PICTURE viewpoint

The big picture viewpoint outlines the solution space and describes potential system-solutions as a set of high-level elements. The big picture viewpoint comprises the following model-types:

• Solution space boundaries (see 7.16)
• Solution space terminology (see 7.17)
• Solution space constraints nomenclature (see 7.18)
• Solution space classifications nomenclature (see 7.19)
• Solution space essential emergent characteristics nomenclature (see 7.20)
• Dependency matrix between problem space essential high-level requirements and solution space constraints vs. solution space essential emergent characteristics (see 7.21)
• Solution space architecture principles nomenclature (see 7.22)
• Dependency matrix between solution space essential emergent characteristics vs. solution space architecture principles (see 7.23)
• High-level illustrative diagrams (see 7.24)
• High-level business map (see 7.25)
• Beneficiaries’ journeys nomenclature (see 7.26)
• High-level reference capability map (see 7.27)
• High-level process map (see 7.28)
• High-level architecture (see 7.29)

3.3 SYSTEM-SOLUTION ENGINEERING viewpoint

The system-solution engineering viewpoint describes the system-solution as sets of artefacts such as capabilities, processes, service, functions, data, information, etc. This viewpoint explains how the system-solution delivers value to its beneficiaries as well as how the system-solution actually runs itself. The model-types of the system-solution engineering viewpoint are applied to any potential system-solution as the whole and some of its elements. The engineering viewpoint comprises the following model-types:

• Capability map (see 7.30)
• Low-level use cases nomenclature (see 7.31)
• Function map (see 7.32)
• Partners nomenclature (see 7.33)
• Process map (see 7.35)
• Services nomenclature (see 7.34)
• Decisions nomenclature (see 7.36)
• Events nomenclature (see 7.37)
• Data schemas nomenclature (see 7.38)
• Information flows nomenclature (see 7.39)
• Document/content classifications nomenclature (see 7.40)
• Key performance indicators nomenclature (see 7.41)
• Reports nomenclature (see 7.42)
• Standards and norms nomenclature (see 7.43)

3.4 PLATFORM ENGINEERING viewpoint

The platform engineering viewpoint covers a platform. A potential system-solutions may contain more than one platform. The platform viewpoint comprises the following model-types:

• Platforms nomenclature (see 7.44)
• Platform overview (see 7.45)
• Platform terminology (see 7.46)
• Platform components nomenclature (see 7.47)
• Platform solutions nomenclature (see 7.48)
• Platform software factory configuration (see 7.49)
• Platform governance, management and operations manual (see 7.50)

3.5 PLATFORM COMPONENT ENGINEERING viewpoint

The platform component engineering viewpoint covers a component of a platform. The platform component viewpoint comprises the following model-types:

• Platform component overview (see 7.51)
• Platform component terminology (see 7.52)
• Platform component capability map (see 7.53)
• Platform component function map (see 7.54)
• Platform component process map (see 7.55)
• Platform component business specifications (see 7.56)
• Platform component information specifications (see 7.57)
• Platform component application specifications (see 7.58)
• Platform component data specifications (see 7.59)
• Platform component infrastructure specifications (see 7.60)
• Platform component security specifications (see 7.61)
• Platform component services and APIs nomenclature (see 7.62)
• Platform component software factory configuration (see 7.63)
• Platform component management and operations manual (see 7.64)

3.6 SOLUTION ENGINEERING viewpoint

The solution engineering viewpoint covers various artefacts of the particular solution. The solution engineering viewpoint comprises the following model-types:

• Solution overview (see 7.65)
• Solution terminology (see 7.66)
• Solution capability map (see 7.67)
• Solution function map (see 7.68)
• Solution process map (see 7.69)
• Solution business specifications (see 7.70)
• Solution information specifications (see 7.71)
• Solution application specifications (see 7.72)
• Solution data specifications (see 7.73)
• Solution infrastructure specifications (see 7.74)
• Solution security specifications (see 7.75)
• Solution services and APIs nomenclature (see 7.76)
• Solution software factory configuration (see 7.77)
• Solution management and operations manual (see 7.78)

3.7 CROSSCUTTING ASPECTS ENGINEERING viewpoint

The crosscutting aspects engineering viewpoint specifies engineering practices for several essential emergent characteristics of the system-solution. The crosscutting aspects viewpoint comprises the following model-types:

• Interoperability aspect (see 7.79)
• Security aspect (see 7.80)
• Privacy aspect (see 7.81)
• Safety aspect (see 7.82)
• Reliability and resilience aspect (see 7.83)
• Low cost of operations and time-to-market aspect (see 7.84)
• Self-reference aspect (see 7.85)

3.8 CORPORATE viewpoint

The corporate viewpoint specifies various governance and management setup of the system-solution. The corporate viewpoint comprises the following model-types:

• Organisational structure (see 7.86)
• Governance structure (see 7.87)
• Project management (see 7.88)
• Corporate manual (see 7.89)
• Independent evaluation (see 7.90)
• Ethics, integrity and ani-corruption (see 7.91)
• Environment and health (see 7.92)

3.9 RISK MANAGEMENT viewpoint

The risk management viewpoint specifies necessary governance practices. The risk management viewpoint comprises the following model-types:

• Risk management aspect (see 7.93)
• Compliance management aspect (see 7.94)
• Regulatory management aspect (see 7.95)
• Crime prevention and detection (see 7.96)
• Auditing (see 7.97)
• Independent investigation (see 7.98)
• Crisis management (see 7.99)

3.10 SOFTWARE FACTORY viewpoint

The software factory viewpoint specifies BizDevOps practices. The whole logic of the software factory is quickly create a simple but complete solution, validate it and gradually enrich it. The implementation viewpoint comprises the following model-types:

• Software factory overview (see 7.100)
• Prototyping practices (see 7.101)
• Engineering practices (see 7.102)
• Assembling practices (see 7.103)
• Testing practices (see 7.104)
• Deployment practices (see 7.105)
• Monitoring practices (see 7.106)

3.11 STANDARDS viewpoint

The standards viewpoint specifies existing and future standards applicable for the system-solution. This viewpoint comprises the following model-types:

• Existing standards nomenclature (see 7.107)
• Potential standards nomenclature (see 7.108)

4 Conclusion

The logic behind the SCRAM and its viewpoints/model-types may be used for other digital domains, such as: Digital Healthcare, Smart Homes, Smart Building, argotech, fintech, edutech, etc.

Thanks,
AS


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