6 Things AI and Machine Learning Reshape in SW

In my recent post, I mentioned that AI and ML challenge architecture, but also offer tools to tackle the challenges. Needless to say, automation of repetitive tasks will change our job descriptions, just like those of our end users.

The SW development lifecycle is changing too. Architects with experience from an environment with external content prosumers or open-source developers, will find some lifecycle changes similar to those two environments.

1. Crowd management

Much of the “crowd” involved is outside the IT organization (e.g. experts in domains other than IT), or even outside the enterprise - not least in Data as a Service offering ML from data sources such as digital twins (of customer-owned equipment, e.g. railroads and trains at Siemens, networks at Ericsson, or farming machinery at John Deere). Architects or CIOs have influence rather than full control, unlike in internal projects.

2. Crowdsourcing

Both the data and some ML-generated logic come from external sources, not least when some ML and computing runs locally on “edge” devices that produce the input data.

3. Adaptive planning

Distinct project phases tend to disappear, partly because of the “crowd” out there, partly because of the explorative nature of ML (“think more like a researcher, less like a programmer”). For example, a partial result of an ML project can hint about additional key domains to drill into, thus widening the scope and postponing the deadline.

4. Incomplete requirements

Customers may have a rather sketchy idea of what they want. “More bang for the buck” wouldn’t hint on “increased harvest, better soils, 80 percent less herbicides due to spraying individual weed plants only”, but ML with fast pattern recognition (in RT field images) does exactly that.

5. Widened job roles

Apart from the SW (development) lifecycle and the nature of new apps, AI reshapes the way they’re developed and thus our roles too. Architects and some devs become even curators of training data sets, co-analysts of ML results, and a guide for experts from non-IT domains, to enable them to apply ML in their specific tasks.

6. A hard core (platform)

The core (e.g. an automated data/ML platform) has to be secure, robust, modular, reliable (fault-tolerant, even on external error), documented and teachable to teams within the enterprise. The ML-generated system has to interoperate with other, programmer-made, systems (pre-ML AI, and other SW). The ML-generated logic has to be auditable and verifiable; indeed, explainability is the door to acceptance in mission-critical apps.

Figure from course AI, Architecture, and Machine Learning (T1913)

by Milan Kratochvil

Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com, main author : UML Extra Light (Cambridge University Press) and Growing Modular (Springer), Advanced UML2 Professional (OCUP cert level 3/3).

  


Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, rules, and design. You can meet him this Spring at public courses (in English or Swedish) on AI, Architecture, and Machine Learning  (T1913),  Architecture (T1101, T1430) or Modeling  (T2715, T2716).