Agile modeling and architecture under paradigm diversity

Many expert notes here mention non-relational paradigms, and these coincide with non-procedural trends in programming — in contrast to a past of procedural/imperative languages hosting non-procedural SQL-only statements; a fine combination in theory, yet often misinterpreted by host-language programmers who habitually hand-wrote loops reading one table line at a time and thus duplicated (in the host language) the tedious work that SQL and RDBMS engines had automated in the first place.

Today, there are several programming paradigms to choose from, in both data-intensive applications and signal-intensive (e.g. the Ericsson ERlang language and its spinoffs), as well as data-architecture paradigms. Also, architects now apply several integration patterns, apart from shared data stores. These trends largely match with the Object Management Group’s initial mission from 1990: to “narrow the communication gap” between IT and business by lifting the level of abstraction. At the same time however, the diversity and rapid pace of hardly-predictable change have made it more difficult to revise the corresponding standards in time.

Given an agile approach, architects communicate via lean documents that address known roles and their expected information needs, although the ever-expanding architectural landscape makes even these needs change faster.

The detailed notation bloat within the Unified Modeling Language often gets in their way (even the slimmed, OMG UML 2.5 spec is still 800 pages), because abstraction is key in the job description of an architect.

The difference in abstraction between two sequence diagrams (architecture level versus detailed level) is visible in this note even if you don’t read a Nordic language. A flight-price calendar on an airline-booking page is put together there, day by day. The text points out that the UML lifeline decomposition (resulting in the detailed right-hand part of the second diagram) is of little importance to architects and can be misleading too, because nobody knows in design time what the actual scenario path will look like, in run time, after access optimization by the DBMS. Given a non-procedural platform, we can suppress the detail without loss of clarity in communication (with most roles).

Microsoft’s architect Steve Cook mentioned already five years ago (on his MSDN blog ) that even mainstream OO PLs are all poorly represented by “vanilla UML class diagrams”.

That’s very true in today’s multitude of paradigms, and evolution of high-level constructs within Java, Dotnet/LINQ, and more (prof. Reichenbach’s big-data article here mentions that declarative languages “can offer the quickest path from idea to implementation”). With multicore and multithread, non-procedural languages also facilitate automation by compilers, which makes them less prone to programmer error than procedural ones. To architecture, they add a reasonably restricted vocabulary (fewer ways to do one thing), improving semantic coherence and standards (and thereby maintainability and quick upgrades, to make the enterprise more responsive).

I recently re-read Steve Cook's and Ivar Jacobson's article about the “road ahead” toward a slim UML3 kernel plus an extension mechanism (2010, on Dr Dobbs), and it makes even more sense with today’s diversified architectural toolbox. They are met with sympathy — but still a way to go, down the standardization road.

Summing up, today’s diversity of integration patterns, programming paradigms, and data-architectures (including in-memory storage & computing) transfers and encapsulates a wider variety of detail into extended platforms and infrastructure. This in turn gives cause for a shift of emphasis in modeling, from “vanilla-design detail” and “vanilla-code generators” to an architect level in encapsulation (of, typically, procedural detail), matching with the Object Management Group’s initial mission.   

// by Milan Kratochvil,  Trainer at Informator, and senior modeling and architecture consultant, Kiseldalen.com, Author (w. Barry McGibbon) of UML Extra Light (Cambridge University Press). Milan and Informator collaborate since 1996 on modelling, UML, architecture, requirements, analysis and design. In June, you can meet Milan at Architecture ( T1101 , T1430 ) or Modeling courses ( T2715, T2716 , in Swedish).

Posted by courtesy of  ODBMS.ORG —The Resource Portal for Big Data, New Data Management Technologies and Data Science