Mens Et Opera - Reloaded

Digital Platforms: between Innovation and Standardization

noreply@blogger.com (Michele Arpaia) — Mon, 20 May 2024 17:45:00 +0000

Last week I attended the #platfmosphere event in Milan, setup and run by Mia-Platform, an excellent Italian cloud native end to end digital platform provider.

There are actually many things to comment on; the event was rich in insights and inspirations, which I hope to soon find some time to articulate. For now, I take this opportunity to explore an aspect which while tangent to platforms, it nonetheless embodies a trait found in any well-architected platform, bringing undeniable benefits throughout the software production chain. I am talking about the supposed "tension" between standardization and innovation, which probably deserves a standalone essay, but an extreme summary doesn't seem impossible.

Standardization vs Innovation

I believe that the long-standing opposition between standardization and innovation is only partially justified. In fact, the real enemy of innovation, I maintain, is not standardization (properly understood) but the centralization of decision-making authorities and the consequent top-down imposition of operational methods by those who are "distant" from the problem domain. These factors can in fact stifle individual initiative and experimentation, essential elements for progress and the development of novel ideas.

I dare to say: innovation is a "negative"* concept, meaning it is defined in terms of what hinders it and not by a prescriptive and a priori rule. To say that there is no recipe for innovation, but there are clearly obstacles to its potential realization. Centralization and regulation by bodies not directly involved in the problem space, are classic obstacles.

In this context, digital platforms represent a peculiar synthesis: on one hand, thanks to their internal dynamism, they promote and incorporate common elements that gradually emerge while seeking efficiency and order, and on the other, they enable an ecosystem of actors to build and innovate according to needs not known a priori. The quality of the interplay between these two planes defines the level of efficacy of platforms.

Standardization (properly understood) is born out of this dynamism: standards often emerge to meet practical needs and real problems encountered by those working on the problem or directly affected by it. When producers and consumers encounters common difficulties, the motivation and the economic and practical convenience to define standards arises. That an external entity, for example ISO, is needed at some stage to certify the standard, does not detract from this "spontaneous" nature of standardization. In fact, this is the final step in a chain of events and ideas that precede the external certifiers.

However, when standardization is not conceived of this way, it often manifests itself as an intent to regulate (in a barely concealed way), perhaps even in the name of nebulous ideals, to favour narrow groups of operators but always at the expense of the end customer (among many examples, see the problems caused by the forced adoption of the USC-C standard).

Fortunately, the history of human progress shows us that despite centralizing forces, "spontaneous" standards in fact facilitate innovation.

I have chosen to tell the story of the role played by the standardization of shipping containers and the consequent unleashed innovation (it will resonate more easily with software professionals for the obvious connections).

The evolution of shipping containers

In the mid-20th century, transportation economics experienced an unprecedented acceleration. Shipping containers, particularly from the mid-19th century, began to play a fundamental role starting with rail transport. From the 1950s onwards, with the push of a pioneer like Malcom McLean, who, overcoming many cultural resistances, effectively proposed the outsourcing of logistics transport and won a contract to build a container terminal at Cam Ranh Bay to handle the transport of military goods by Sea-Land container ships from California to Vietnam. Nevertheless, for about the next twenty years, many shipping companies used incompatible dimensions for containers and corner fittings used to lift them. This, in turn, required multiple variants of equipment to load and unload containers and made it difficult to develop a complete logistics system.

A real problem that the community, that is, those directly involved and impacted by the problem, solved by standardizing - despite political interference to seize control - the loads through the container, enabling intermodal transport, i.e., the use of different means of transport (ships, trains, trucks) without any intermediate handling of the goods and with a drastic reduction in the labour needed for unloading and loading operations, resulting in significant cost and time advantages**.

Containerized freight traffic has been one of the greatest transformations in the field of transport in the era of mechanical propulsion, and it was a true and almost unexpected revolution after a nearly traditional recovery of traffic in the immediate post-war period.

Tools for Innovation

We like to think that innovation derives from unfettered chaos. Wrong! It is the search for order that generates great innovative breakthroughs. It is misleading to oppose standards and innovation. Generally, two types of errors are made: the error that standardization is the child of centralized "governance," or its opposite, that innovation arises or even emerges from a supposed melting pot of ideas, feelings, intuitions, and thus from a fundamentally chaotic and disorganized setup. In reality, the motivated search for innovation inevitably generates "products" that are usable across the board and thus standardizable. This is the real measure of progress.

* I have borrowed this concept from Isaiah Berlin who defines "negative liberty" as the absence of coercion or interference with agents' possible private actions, by an exterior social body

** Impacts of Containership Size, Service Routes, and Demand on Texas Gulf Ports (bts.gov )

A Software Design Manifesto - The Relevance of Mitchell Kapor ideas

noreply@blogger.com (Michele Arpaia) — Fri, 08 Mar 2024 18:36:00 +0000

Writing a Manifesto may be cool. It may make you feel belonging to something historically relevant. But they are generally subjects to the law of unintended consequences.

There are exceptions, naturally. I believe Mitchell Kapor A Software Design Manifesto is one of those few exceptions.

Is Software Design really Dead?

noreply@blogger.com (Michele Arpaia) — Wed, 06 Mar 2024 09:46:00 +0000

Over an interesting post by @Michele Sollecito where he maintains that software development is all design, there's been a lively conversation in the comment.

I said in one of the comments that "Design is Dead" and the provocation was picked up. Here a brief comment on why I believe so. For the long answer, I am afraid you have to wait for my paper to be in a readable draft state (and please don't crowd 😀).

Premise

Martin Fowler in a 2004 long article maintained that software design has changed nature and as a result it is alive though morphed into something else.
Jim Coplien, argues, correctly in my option, that it is wise and experience bears this out to get the structure upfront, otherwise you risk driving yourself into a corner, architecturally.

I could mention hundreds. This is to set the stage i.e. it is a fundamental debate, and it’s not settled. Unless we introduce beliefs in the mix.

Clarification: Talks of "design" abounds, they are everywhere. But if you get a bit closer, you'll notice that it's not about the design itself, but the process of design. Design thinking or agile in the context of software development are two paradigmatic examples.

Clarification: I meant that SD has been killed. But as Fowler indicates, it does not mean that there is no software design today! It’s just morphed. A simple Google search for “software design” yields ca. 30mil results.

Short answer: In the mainstream, the code is the design. At some point, this became a sort of truism, encouraged by many well-known authors, methodologists, and gurus. I didn’t buy it.

Considerations.

There is a general agreement that design is a set of decisions. As a result, the different design approaches propose different ways to come to a decision e.g. upfront school, emergent design, the pattern school, MDA, Design by Contract, etc. No beliefs, just options with constraints and sweet spots. That’s why it is hard to be a software designer.
But there is more, and that’s what I considered to be moribund. The disproportionate emphasis on the piecemeal approach, namely, you start building based on what you need now, on what you know now, and along the way the structure will be built and changed as conditions change. While it is easy to recognize that software by nature is subject to continue changes (because the environment changes, so in sense software artefacts are derivative of the environment where they are executed), it is also safe to admit that this has often led to failure to deal effectively with the “problem” so that inevitably the totality of the "problem" is not considered. In these cases, some crucial elements may be excluded from the formulation of "a solution." Furthermore, this approach may lead to little considerations to reasonable range of alternatives or perspectives.
There is even more (for instance the design of Concepts as the work of Daniel Jackson illustrates, or the insights in the A Software Design Manifesto by Mitchell Kapor) but hopefully it is clear by now what I mean when I say “design” is dead.

In my view we have yet to build the intellectual foundations on which the field of software design can be based. In other design disciplines and the field of HCI, design has flourished but the particular, distinctive qualities of software design have yet to be fully articulated. My point is that as an industry we are pushing this back. Unnecessarily.

*The picture is from "Why Buildings Fall Down" book cover, by Mario Salvadori.

Overconfidence kills software projects

noreply@blogger.com (Michele Arpaia) — Tue, 05 Mar 2024 10:09:00 +0000

𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗳𝗮𝗶𝗹.
We all know that. Statistics are staggering. Or just misleading. Bottom line is that every one in the industry knows that IT projects fail often, many have experienced it first hand.

Two interrelated thoughts come to mind. They may not resonate with you - which is, incidentally, a very good news!

💭 [𝙼&𝙾 𝙲𝚘𝚗𝚓𝚎𝚌𝚝𝚞𝚛𝚎 #2] 𝚃𝚑𝚎𝚛𝚎 𝚒𝚜 𝚗𝚘 𝚠𝚊𝚢 𝚢𝚘𝚞 𝚌𝚊𝚗 𝚐𝚎𝚝 𝟾𝟶% 𝚌𝚎𝚛𝚝𝚊𝚒𝚗𝚝𝚢 𝚒𝚗 𝚊𝚗𝚢 𝚎𝚗𝚍𝚎𝚊𝚟𝚘𝚞𝚛 𝚠𝚑𝚎𝚛𝚎 𝚙𝚎𝚘𝚙𝚕𝚎 𝚊𝚛𝚎 𝚒𝚗𝚟𝚘𝚕𝚟𝚎𝚍

💭 [𝙼&𝙾 𝙲𝚘𝚗𝚓𝚎𝚌𝚝𝚞𝚛𝚎 #3] 𝚂𝚘𝚏𝚝𝚠𝚊𝚛𝚎 𝙳𝚎𝚟𝚎𝚕𝚘𝚙𝚖𝚎𝚗𝚝 𝚙𝚛𝚘𝚓𝚎𝚌𝚝𝚜 𝚊𝚛𝚎 𝚕𝚊𝚛𝚐𝚎𝚕𝚢 𝚏𝚕𝚊𝚠𝚎𝚍 𝚋𝚢 𝚝𝚑𝚎 𝚘𝚟𝚎𝚛𝚌𝚘𝚗𝚏𝚒𝚍𝚎𝚗𝚌𝚎 𝚘𝚏 𝚝𝚑𝚎 𝚖𝚊𝚗𝚊𝚐𝚎𝚖𝚎𝚗𝚝.

All the "explanations" about projects failure you read in (good) literature are an outpouring of (2) and (3).

Innovation in Software Development

noreply@blogger.com (Michele Arpaia) — Mon, 04 Mar 2024 08:53:00 +0000

At organizational level, software development is a flatland, populated by odd creatures. Lots of alchemy, little chemistry.

How to stand out and be innovative? A legit question.
When it comes to innovation I discount virtually all the recipes foisted on to us by methodologists, gurus, charismatic figures, mesmerizing narratives, and so forth.
Innovation is a "negative" concept*, namely, it is defined by pointing out what stifles it. In other words the best we can do is to set out the conditions to let people innovate, potentially.
In this context, fostering an innovative environment for software development is a matter of taking stuff away :-) What stuff? My take. No prescriptive recipes, no universal principles - just observation over the years:

1️⃣ No principles: they are all good and agreeable but provide very little guidance. For example: in many quarters software (design) has been trivialized to SOLID, YAGNI, Beck's 4 principles to name a few.
2️⃣ Don't start with patterns. Patterns may be a landing space, once the problem has been dissected. Further, patterns tend to optimise locally escaping the quasi-fractal nature of software and related artefacts.
3️⃣ No dogmas. The socio-technical aspects of developing software should suffice to leave dogmas at the door. It is a complex endeavour, little room for silver bullets.
4️⃣ No guru driven development. They too should be shown the door :-) Seriously, lots of anecdotes, charisma, cool slides, but little substance.

I am pompously 😅 writing down a series of conjectures...prefixed as [𝙼𝚎𝚗𝚜 𝚎𝚝 𝙾𝚙𝚎𝚛𝚊 (𝙼&𝙾) #] . They help me reason over stuff that I learn and practice. Here the first one:

[Mens et Opera #1]: Innovation is more a matter of setting the table than to dictate the menu.

*Inspired by the concept of "negative liberty", i.e. freedom from interference or restraints.

Hayek on Complexity and Knowledge

noreply@blogger.com (Michele Arpaia) — Fri, 01 Mar 2024 11:26:00 +0000

In Software Development, knowledge acquisition and transformation on one hand, and internal and external complexity, on the other hand, are two interconnected and inseparable aspects of the same endeavour.

F. Hayek, a towering figure in economics, and a major member of the Austrian School of Economics, put it simply.

“𝑻𝒉𝒆 𝒄𝒖𝒓𝒊𝒐𝒖𝒔 𝒕𝒂𝒔𝒌 𝒐𝒇 𝒆𝒄𝒐𝒏𝒐𝒎𝒊𝒄𝒔 𝒊𝒔 𝒕𝒐 𝒅𝒆𝒎𝒐𝒏𝒔𝒕𝒓𝒂𝒕𝒆 𝒕𝒐 𝒎𝒆𝒏 𝒉𝒐𝒘 𝒍𝒊𝒕𝒕𝒍𝒆 𝒕𝒉𝒆𝒚 𝒓𝒆𝒂𝒍𝒍𝒚 𝒌𝒏𝒐𝒘 𝒂𝒃𝒐𝒖𝒕 𝒘𝒉𝒂𝒕 𝒕𝒉𝒆𝒚 𝒊𝒎𝒂𝒈𝒊𝒏𝒆 𝒕𝒉𝒆𝒚 𝒄𝒂𝒏 𝒅𝒆𝒔𝒊𝒈𝒏. 𝑻𝒐 𝒕𝒉𝒆 𝒏𝒂𝒊𝒗𝒆 𝒎𝒊𝒏𝒅 𝒕𝒉𝒂𝒕 𝒄𝒂𝒏 𝒄𝒐𝒏𝒄𝒆𝒊𝒗𝒆 𝒐𝒇 𝒐𝒓𝒅𝒆𝒓 𝒐𝒏𝒍𝒚 𝒂𝒔 𝒕𝒉𝒆 𝒑𝒓𝒐𝒅𝒖𝒄𝒕 𝒐𝒇 𝒅𝒆𝒍𝒊𝒃𝒆𝒓𝒂𝒕𝒆 𝒂𝒓𝒓𝒂𝒏𝒈𝒆𝒎𝒆𝒏𝒕, 𝒊𝒕 𝒎𝒂𝒚 𝒔𝒆𝒆𝒎 𝒂𝒃𝒔𝒖𝒓𝒅 𝒕𝒉𝒂𝒕 𝒊𝒏 𝒄𝒐𝒎𝒑𝒍𝒆𝒙 𝒄𝒐𝒏𝒅𝒊𝒕𝒊𝒐𝒏𝒔 𝒐𝒓𝒅𝒆𝒓, 𝒂𝒏𝒅 𝒂𝒅𝒂𝒑𝒕𝒂𝒕𝒊𝒐𝒏 𝒕𝒐 𝒕𝒉𝒆 𝒖𝒏𝒌𝒏𝒐𝒘𝒏, 𝒄𝒂𝒏 𝒃𝒆 𝒂𝒄𝒉𝒊𝒆𝒗𝒆𝒅 𝒎𝒐𝒓𝒆 𝒆𝒇𝒇𝒆𝒄𝒕𝒊𝒗𝒆𝒍𝒚 𝒃𝒚 𝒅𝒆𝒄𝒆𝒏𝒕𝒓𝒂𝒍𝒊𝒛𝒊𝒏𝒈 𝒅𝒆𝒄𝒊𝒔𝒊𝒐𝒏𝒔 𝒂𝒏𝒅 𝒕𝒉𝒂𝒕 𝒂 𝒅𝒊𝒗𝒊𝒔𝒊𝒐𝒏 𝒐𝒇 𝒂𝒖𝒕𝒉𝒐𝒓𝒊𝒕𝒚 𝒘𝒊𝒍𝒍 𝒂𝒄𝒕𝒖𝒂𝒍𝒍𝒚 𝒆𝒙𝒕𝒆𝒏𝒅 𝒕𝒉𝒆 𝒑𝒐𝒔𝒔𝒊𝒃𝒊𝒍𝒊𝒕𝒚 𝒐𝒇 𝒐𝒗𝒆𝒓𝒂𝒍𝒍 𝒐𝒓𝒅𝒆𝒓. 𝒀𝒆𝒕 𝒕𝒉𝒂𝒕 𝒅𝒆𝒄𝒆𝒏𝒕𝒓𝒂𝒍𝒊𝒛𝒂𝒕𝒊𝒐𝒏 𝒂𝒄𝒕𝒖𝒂𝒍𝒍𝒚 𝒍𝒆𝒂𝒅𝒔 𝒕𝒐 𝒎𝒐𝒓𝒆 𝒊𝒏𝒇𝒐𝒓𝒎𝒂𝒕𝒊𝒐𝒏 𝒃𝒆𝒊𝒏𝒈 𝒕𝒂𝒌𝒆𝒏 𝒊𝒏𝒕𝒐 𝒂𝒄𝒄𝒐𝒖𝒏𝒕.”

It is true and insightful on multiple levels. To illustrate: take the way software architectures are generally built: there's an hidden assumption that the future is made of a sequence of static "images" and as a result the architecture/structure reflects that perspective. Unfortunately, there will always be an event or a stressor happening in the environment that the architecture was not designed for, forcing you to make a decision that is not completely under your control. Generally, when this hits, it is painful, and will likely break your architecture (or put your system out of balance).

The reality is, as alluded by Hayek, the environment your software will be deployed is socio-economically complex and unpredictable.

This is what makes building software very hard (and very human):

⭕Embedding flexibility in the functional space (I called this forward thinking mode) to accommodate change

⭕Evolving the architecture based on unpredictable usage patterns (backward thinking) by stacking residues (see Residuality Theory by Barry O'Reilly).

No advanced AI can help here, sorry. Apart from the desired efficiency gain we demand from technology.

On Bullshit, philosophically.

noreply@blogger.com (Michele Arpaia) — Tue, 27 Feb 2024 09:10:00 +0000

I was once asked during an intervierw what would be my top three "professional" values. My answer was unexpected in fact I rushed to qualify it a bit.

I said "I find hard to deal with bullshits and bullshitters".

Philosopher Harry G. Frankfurt's famous book came to rescue me. Frankfurt's thesis is serious and important. Bullshitting, Frankfurt argues, is not the same as lying.

The liar, like the truth-teller, cares about what is true. The difference is that the truth-teller conveys it while the liar wants to cover it up. The bullshitter, by contrast, doesn’t really care one way or the other about the truth.

To quote him:

The bullshitter may not deceive us, or even intend to do so, either about the facts or about what he takes the facts to be. What he does necessarily attempt to deceive us about is his enterprise. His only indispensably distinctive characteristic is that in a certain way he misrepresents what he is up to.

But then surely almost every liar is, at heart, a bullshitter.

My experience has taught me that the surest cure for bullshit is exposing it to the scrutiny of people who truly, deeply understand a problem through years of lived experience.

Peter Naun on Programmers Mental Models

noreply@blogger.com (Michele Arpaia) — Thu, 22 Feb 2024 09:55:00 +0000

In a nutshell, to exemplify the idea that software development should fundamentally focus on knowledge acquisition (from the envirnoment the software will live in), and building problems frames (see Jackson) to inform the structure of the architecture (design), I sketched the following. It is simple, not powerfully explanatory, but it is the beginning of something I am working on. So don't shoot me just yet ;-)

Now, looking at some literature to further back up or challenge or enrich this idea, I came across this 1985 article by Peter Naur: Programming as Theory Building.

He says a programmer’s main activity isn’t coding, it’s creating a theory of the problem at hand and its solution. This theory is implicit knowledge, which can’t be written down.

Sure, I can transmit knowledge via documentation. But you can't understand my code as well as I do unless oyu acquire the theory I built in my head, and you can't get that by reading my docs or my code.

In other words, the actual code is not the point of programming ie the code is not an asset. Instead, the real goal of the software development team is to understand in depth the problem that they are trying to solve.

Problem View vs System View in Software Development

noreply@blogger.com (Michele Arpaia) — Wed, 21 Feb 2024 10:38:00 +0000

One of the advantages to consider Software Development as a knowledge-acquisition activity, is its inner force to balance the pull to envision the system (design) and the importance of learning the problem first.

There it is, the “problem”, learning the problem first, is rarely an activity in most methodologies.

I am grateful to the immense work produced and clearly articulated over the years by Michael Jackson*, the “father” of problem Frames Analysis.

As Jackson argues, the issue is partially due to the fact that the world is is physical and therefore informal. This poses a great challenge in software development: formalization i.e. capturing in symbolic representation a worldly computational problem so that the statements obtained by following rules of symbolic manipulation are useful statements once translated back into the language of the world.

There lies the core expertise for any software analyst: learn and frame the problem.

I would argue that the articulation of the problem influences the shape of the software (design), the economic investments (decisions), the expected revenue (value), and ultimately the utility of the software being developed (fit for purpose).

Software is a Knowledge Medium. Forget that at your Peril!

noreply@blogger.com (Michele Arpaia) — Tue, 20 Feb 2024 13:53:00 +0000

Legacy is something of value you leave for the next generation. At what stage in the history of Software Engineering, "legacy" has become a curse?

Software Factory? What a heck is supposed to mean? Building software as in a production line?

Developer Productivity. The worst of all myths, introduced by maître à penser who do not have the slightest idea of what software really is. A myth perpetuated with the help of pretentious consulting firms...

Tech Debt. Another of those topics that gives you an air of expertise like an economist, but it makes no sense at all as a metaphor.

Shall I continue? A couple more:

Process as the be-all and end-all of software development, because we are persuaded that software is an engineering discipline only. You have the process, you have the product.

Aside. To my Agile friends, I am well aware of the first principle in the Manifesto. However, I spot value as a projection of what is done in the field, and not from first principles, and as a result I observe just the opposite: processes and tools often trump individuals and interactions.

So what lies at the heart of this disastrous misapprehension in our field? Read on.

I maintain that the crux of the matter lies in a profound misconception of what software really is.

Software is knowledge. It is the fifth medium where we store the knowledge (the other four are: DNA, Brain, Hardware Design, Books [1])
Software is executable knowledge. A very peculiar trait of this medium
Software is a cost. It is the knowledge you have to acquire, codify and deliver to get to business impacts.
Software is not a product. Mistaking means (coding) for ends (business impacts) is a fallacy. Go and give it a proper name!
The product is the codified knowledge contained in the software
Software is complex (intrinsically - see Brooks[2]). As such, it is not reducible to its parts as in many engineering disciplines artefacts
Its elasticity is a double-edged sword. As knowledge decays, software ages [3]

As a result, I'd encourage to see Software Development (SD) from a different perspective:

SD is not a product-producing activity.
SD is a knowledge-acquisition activity.
Knowledge is dynamic and decaying. SD focuses on bringing down the ignorance from unknown-unknowns to first orders of ignorance. [1]
SD is an effort to morph knowledge into artefacts e.g. code, models, documentation, etc.
SD is not about coding only! The less you code to get to the business impacts, the better.
SD is an exercise in making continuous decisions and shaping material (knowledge is the raw material)
Decisions regarding what to build now, what to defer, what to invest on (by paying a little fee now), what to abandon. There are decisions you control and others you don't e.g. external stressors from the environment (see for example Residuality Theory [4])
Shaping material to build artefacts that responds to human needs (or as the architect Christopher Alexander would put it: create forms to fit a context) [5]
Wise investments in SD lie in balancing those two forces: decisions and what materials to shape accordingly. It is not a matter of being agile; rather, its mostly to do with having an economic acumen and being laser focused on business impacts.
SD today is in a pre-engineering phase analogous in many respects to the pre-engineering phases of the now traditional engineering disciplines.[6] This is not bad news just an urge to face reality.

n Language always tells a story. Legacy, tech debt, etc. they all tell a story of a largely misconception begot by a distorted way to understand what software is. For example, we think about technical debt because we live with the assumption that software is an asset! And so on.

The last 60 years of software development are certainly only the beginning of our field and represent a short period if measured in historic terms. Nevertheless, it is helpful to try to identify some threads that could form a road map into the future. As historians usually argue, the only purpose to study history is to learn about the future. Unfortunately, our industry tends to ignore its one history.

As the software engineering profession matures, let us not fall again and again in the trap of trying to mimic or force-fit approaches that did work elsewhere, and let us looks at what makes the true nature of software, what distinguish its object, totally artificial, from that of other disciplines, closer to the natural sciences. It is engineering, but not quite the same.

***

Phillip G. Armour, The Laws of Software Process: A New Model for the Production and Management of Software, Auerbach Publications (2003).
Frederik Brooks, No Silver Bullet Essence and Accidents of Software Engineering, IEEE Computer Society, vol. 20, no. 4, pp. 10-19, April 1987
David Parnas, Software Aging, Proceedings - International Conference on Software Engineering, June 1994
Barry O'Reilly, The Philosophy of Residuality Theory, Procedia Computer Science, Vol. 184, 2021
Christopher Alexander, Timeless Way of Building, Oxford Press, 1979
R. L. Baber, Comparison of electrical "engineering" of Heaviside's times and software "engineering of our times, IEEE Annals of the History of Computing, vol. 19, no. 4, pp. 5-17, Oct.-Dec. 1997

"Mens et Opera" defined

noreply@blogger.com (Michele Arpaia) — Mon, 19 Feb 2024 07:41:00 +0000

Da anni il mio motto richiama l'importanza del pensiero come lavoro.

Mens et Opera, questo il motto.

Innanzitutto: il lavoro è costrutto intellettuale, implica la libera e non faticosa iniziativa del lavoro del pensiero: atto cioè attivo a mobilitare, propiziare altri al proprio beneficio (domanda).
E il pensiero è lavoro senza fatica.

Il lavoro è legge fisica, è moto cioè investimento, è l'impresa della soddisfazione che mette in moto un altro a favore del soggetto operante - divisione del lavoro. Questo genera domande a titolo pieno (ma non ci sono domande che non siano anche offerte).

Il lavoro non-lavoro è l’obiezione di principio alla produzione del proprio bene per mezzo della soddisfazione data a un altro. Si chiama invidia.

Il lavoro libero (quello testé definito) ammette riposo non come dopolavoro, ma come già interno al lavoro stesso.

Da qui quel Mens et Opera.

___________________

For years, my motto has emphasized the significance of thought as work.

Mens et Opera, this is my motto, latin for Mind and Work.

First and foremost: work is an intellectual construct, implying the free and effortless initiative of thought labor: an active act aimed at mobilizing, fostering others for one's own benefit (demand). *

And thought is work without toil.

Work is a physical law, it is motion, i.e., investment, it is the undertaking of satisfaction that sets another in motion in favor of the operating subject - division of labor. **

This generates demands with full rights (but there are no demands that are not also offerings).

The principled objection to producing one's good by means of generating satisfaction to another is called envy. It is the opposite of work.

The work so defined allows for rest not as after-work, but as already internal to the work itself.

Hence, Mens et Opera.

*This exchange is complicity. Marx would retort that this exchange is marked with conflicts. He was wrong.

**Central to Marx ideology was the alienation caused by enforcing over individuals the "division of labor". He was wrong.

In Memoriam: Frederick P. Brooks, Jr. 1931-2022

noreply@blogger.com (Michele Arpaia) — Sat, 02 Dec 2023 20:47:00 +0000

The death of Fred Brooks is a big loss. The man deserves to be remembered, re-discovered, appreciated by the young developers tornados, and by the management, by the whole industry! Here the link to his seminal work: no silver bullets.

R.I.P.

Artificial Intelligence i.e. Doing without Thinking

noreply@blogger.com (Michele Arpaia) — Thu, 30 Nov 2023 20:58:00 +0000

AI may prove more dangerous as it advances, but it will never generate actual intelligence so long as the basic assumptions of the field remain unchanged. Take the LLMs: they scan and process texts often in a way that is indistinguishable from human output, while lacking any understanding or cognitive ability. It is undeniable even to the most sceptical to recognise LLMs extraordinary capabilities.

It doesn’t help the cause to be sceptical or optimistic, though. What I believe is helpful, is to see AI for what it is - #realAI. It is probably not sexy nor very appealing – a real disappointment for those in the business of generating hot air.

When IBM’s Deep Blue won against Garry Kasparov in 1997, the Chess grandmaster said: “Anything we can do (…) machines will do it better (…) If we can codify it, and pass it to computers, they will do it better.” There is a clue in Kasparov’s words: i𝑖𝑓 𝑤𝑒 𝑐𝑎𝑛 𝑐𝑜𝑑𝑖𝑓𝑦 𝑤ℎ𝑎𝑡 𝑤𝑒 𝑑𝑜. The thing is that we are still trying to understand how is it that human beings are intelligent. Many aspects of our cognition remain mysterious; we are yet to codify the process. Could it be that the road to Artificial General Intelligence is closed by our lack of clarity regarding how the brain works?

Luciano Floridi has some interesting remarks: “We have not even yet comprehended how the human brain functions; we do not know what consciousness is. We are beginning to grasp some ideas now, but it remains a largely uncharted territory. 𝗛𝗼𝘄, 𝘁𝗵𝗲𝗻, 𝗰𝗮𝗻 𝘄𝗲 𝗿𝗲𝗽𝗿𝗼𝗱𝘂𝗰𝗲 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝗼𝗳 𝘄𝗵𝗶𝗰𝗵 𝘄𝗲 𝗵𝗮𝘃𝗲 𝗻𝗼 𝗸𝗻𝗼𝘄𝗹𝗲𝗱𝗴𝗲? 𝗦𝗰𝗵𝗼𝗹𝗮𝗿𝘀 𝘄𝗵𝗼 𝗯𝗲𝗹𝗶𝗲𝘃𝗲 𝘁𝗵𝗮𝘁 𝗮𝗿𝘁𝗶𝗳𝗶𝗰𝗶𝗮𝗹 𝗶𝗻𝘁𝗲𝗹𝗹𝗶𝗴𝗲𝗻𝗰𝗲 𝗰𝗮𝗻 𝗮𝘁𝘁𝗮𝗶𝗻 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗽𝗼𝘀𝗶𝘁 𝘁𝗵𝗮𝘁 𝘁𝗵𝗲 𝗵𝘂𝗺𝗮𝗻 𝗯𝗿𝗮𝗶𝗻 𝗶𝘀 𝗮 𝗺𝗮𝗰𝗵𝗶𝗻𝗲. However, the analogy of the brain to a computer is losing its grip as we now know it is not so [...] we are moving on to the next technology, the quantum computer, repeating the same mistake.” Spot on.

I am increasingly becoming persuaded that another 𝑨𝑰 𝑾𝒊𝒏𝒕𝒆𝒓 may come – but it is avoidable. And if it comes, it can help cool things down a bit. I maintain that we would make some real progress the moment we 𝒔𝒕𝒐𝒑 𝒂𝒏𝒕𝒉𝒓𝒐𝒑𝒐𝒎𝒐𝒓𝒑𝒉𝒊𝒔𝒊𝒏𝒈 𝑨𝑰, weak, strong, general, and whatnot. AI is a machine designed to process data. That’s as far as it goes. A human, on the other hand, is something far more complex than a machine that processes information. We do process information, but we also have emotions, creativity, critical reflection and intuition, as well as many other qualities, not to mention a biology that a machine cannot replicate.

Let’s cut through the AI hype that’s permeating the current 𝒛𝒆𝒊𝒕𝒈𝒆𝒊𝒔𝒕 in the business world.

The Peter Principle

noreply@blogger.com (Michele Arpaia) — Fri, 24 Nov 2023 21:06:00 +0000

I must admit that I have encountered a few meanigful instances of "The Peter Principle" througout my career. The concept seems amusing; in the author's words: “You will see that in every hierarchy the cream rises until it sours.”

In short it goes like this: an employee performs well, is rewarded with a promotion, excels in that role, and is promoted again. This cycle continues until the point where the individual is no longer performing at a level deserving of a promotion, leaving them at a level where they are overmatched by the demands of the job—essentially, "incompetent."

Two simple observations:

This is not a law - it does not invariably and inevitably reflect how organizations work, or society at large for that matter. It is intentional, a result of a certain way of doing stuff commonly referred as Culture. To illustrate (from my experience): the best salespeople generally become the worst sales managers. Removing a high-performing sales associate from the line potentially upsets his client relationships and puts the revenue of those accounts in jeopardy.
Hierarchy is not the villain. It is easy to blame the hierarchy as the root cause of the problem. But this is s shallow analysis. Hierarchies, properly understood, are a natural phenomenon: if I am a good developer this will likely establishes me as a leader.

Software as A Human Activity Between Art and Science

noreply@blogger.com (Michele Arpaia) — Wed, 22 Nov 2023 21:09:00 +0000

In preparation for my new role at VMW last year, I started to brush up on my application and development skills: I played with some little toy programs in Java and Scala and engaged with some design artifacts (yes, those amazing UML colored diagrams to reasons over problems!). I took time to write a few notes down along the way and left a few points to ponder.

With some spare hours in recent weeks, I have dug up those shaky notes and tried to mold them into a more consumable piece of information. My intention is not to delve into technicalities or technological debates. I am simply walking in the shoes of thousands of customers and organizations I have come across in my career, inviting to look beneath the surface of our pop IT culture (to paraphrase Alan Kay) and aiming to give a more nuanced view on what building software is about. The good news is that I am not inventing much or speculating over – I am going to be much more descriptive than normative so to speak. In a way I am like a reporter from the front lines. Needless to say, my own ideas and suggestions will either be obvious from the context or be clearly called out.

Given the variety of topics I recollected, I thought to boil all of them down to the following.

Software As A Human Activity Between Art and Science,
The Nature of Software,
Orders of Ignorance and Complexity,
Four-dimensional Space: Design, Construct, Runtime, Artifact,
Software Design – Who Killed It?,
Disenchanted by Modern Software?
Is AI Eating the World?

A note for the hard cores out there: the software industry's evolution hasn't been a linear ascent – the latest is not necessarily the greatest.

Let’s now turn to the first one.

I will closely address the arguments about the nature of software in the next post. I now want to simply illustrate a particular angle from where software engineering manifests a peculiar “behavior” when compared to development of modern science and the arts. It is often said (but it is controversial in my opinion) that software has a dual nature: scientific and artistic. On that assumption, let’s see how it compares to arts and science. The comparison is mainly hystorical and reflects the internal and external general dynamics observable by virtually everyone.

Science vs. Arts

There is a striking contrast between the development of modern science and the arts. No one would say of a work of literature or music that it was better than an earlier work just because it was later!

A later masterpiece of say Luciano Berio is not, because of its modernity, better than Beethoven’s Violin Concerto. There just is no scale on which one could judge such things, once a certain level of expressive adequacy has been reached. It seems like in arts the past experience is continuously alive because the aim is not to demonstrate a particular truth, but to enrich our perception of the truth (or beauty). There is also another key element: in arts like music, literature, etc…as T.S. Eliot once remarked, more it’s known than our predecessors because what we know is their work.

On the other hand, the growth in science has a different trajectory. Here we are able to specify a clear aim that is our incremental understanding of the world. Thus, Copernicus’s heliocentric picture of the universe was better than Aristotle’s geocentric picture, and Einstein provided a better picture of the Newtonian gravity, etc. It’s like science can be likened to a vast graveyard of outdated theories superseded by superior ones that will at some point be in turn replaced (Note: I am adopting a Popperian-like philosophy of science). You got the drill.

What does Software stand for?

Under the umbrella term ‘Software’ I include: software engineering, programming, methodologies, user experience, management, procurement. And I am describing what I see in the main, and a general trend. With that in mind, let’s see where Software stands in contrast with science and arts.

Scientists don’t have to know their history because it is a history of discarded theories, and which are regarded as giving far less true information about the world than their successors. They can be revived as historical curiosities. In Software industry a very similar attitude can be found. The tendency is to dismiss past theories, structures, frameworks, tools as relics or at least surpassed, admitting that they were useful but now we do and know better. Examples are overwhelming. Take for instance the “Microservices” article of faith. It goes like this: Monolithic applications are bad, we have evolved from that primitive way of building software, and moved to Microservices to ensure more <add as many success words as possible like scalable, decoupled, efficient, etc.>. Needless to say, here the Monolithic has been portrayed as the antagonist (inappropriately), with everything contrary to it depicted as good. This is a typical, by-the-book application of the Strawman Fallacy. A common pattern.
As I mentioned earlier, in the arts it is a core feature to immerse yourself with past, ancient authors and their work. Software engineers rarely know their predecessors: you mention that say Information Hiding dates back to Parnas, and actually reading On The Criteria… could give you good insights about making better modular software. You won’t get much traction, nor much gratitude for those whose shoulders we are standing on.
Edward Yourdon popularized the concept of “Good Enough Software”. It was so potent that, despite Yourdon intentions, if you dare to even hint at a critique, you are swiftly labeled as a purist. On reflection, I must say that while in Software Engineering this might be a good idea under some circumstances, I would argue that in science for example it's a bad idea tout court. In arts, it’s rare that an artist advocates a good enough piece of art, making their customers aware of his intentions (Artist: “I was anxious to sell you this drawing, I didn’t want to further delay its launch. But it’s good enough to be sold”). The point is that Software is the only artefact that can be shipped and intentionally launched to hit the market not necessarily with high quality features. The fact that in practice good-enough software is rarely good enough is a rant that I will voice when we talk about the death of software design.

In a nutshell, Software Development is a very peculiar human activity that is modulated by different forces and polarities, which are hard to reduce to one single linear driver. The mix of fads, unfettered credos, the spade of tools and apps delivered every microsecond often hide the more fundamental forces that animate the industry:

hard-work to acquire the right knowledge to solve real problems,
difficulty to channel a system vision through different layers of organizational structure,
represent domain knowledge in an executable way,
navigate through the inevitable fumes of vendor boastful claims,
make economic sense in choosing what to build and what to buy

The arts and science dichotomy proves to be very inadequate to make sense of this articulated human activity. I will come back to this in the next post of the series.

***Cover: the book of Eliane Strosberg retraces in the links between art and science through over 250 illustrations and examples taken from architecture, painting, the decorative arts, chemistry; astronomy, biology or other disciplines. A straightforward style for the general public.

chatGPT between bias and stupidity

noreply@blogger.com (Michele Arpaia) — Mon, 20 Nov 2023 20:47:00 +0000

My son and I recently had a bit of fun experimenting with GPT. We basically instructed GPT to impersonate a specific persona.

We crafted a detailed profile encompassing beliefs, physical traits, cultural background, language, opinions, political leaning, and a few likes and dislikes.
We then instructed it to interact with us only and only through the lens of this fictional character.
Guess what? GPT struggled to adhere to the designated personality. It seemed to have difficulty fully embracing the persona's credo. Upon some gentle and repeated reinforcement :-) it began to align its answers more closely but with a caveat for each answer!

We repeated the experiment. This time with an opposite personality. This time around, GPT sailed smoothly with almost no caveats. A stark contrast to the previous experiment.

What did this show us?

Apart from the obvious, I want to ask a few questions to those who have more accurate knowledge and understanding of GPT and more generally about GenAI.

Is that issue (or dare I say? the bias) just a matter of the type of data fed into it?
How has the defense of "bias" been constructed?
More and more of the content generated will feed back into GPT. There might be a point of no return. Not a question but an ask for comments.
It is clear that there is no semantic level here. AI merely uses syntactic rules to manipulate symbol strings. No intelligence, just sophisticated math, compute and lots of data. This is not a question nor a request for comments. It is my bias :-) just correct me!

That said, there is #realAI. The quest for more innovation, more efficiency in many quarters is wanting and #realAI is the answer, like the progress of science and technology has been for millennia.

What's the next wave of PIM? Part 4 (Final)

noreply@blogger.com (Michele Arpaia) — Fri, 24 Jun 2016 05:58:00 +0000

The question of whether PIM is an “MDM use case” or an “ECM use case” (ECM stands for Enterprise Content management), or a combination of both (as usual) has become the topic du jour in certain parts of the blogosphere. I am glad that I’ve contributed to raise awareness around this topic with my series of posts (here, here, here, here for an introduction).

Let me try to visualise these two worlds. Let’s start with MDM. The much respected Henrik Liliendahl has a nice diagram to exemplify the MDM world.

Quick digression: As you probably know, Gartner is now revisiting their MDM quadrants to be more use case driven…yes, in 2016. Better late than ever ;-)

This is how the MDM world works: you have multiple domains e.g. Customer, Products, which have different processes attached to their lifecycle.
For example, products go through a “making” and “selling” process while customers “making process” is a completely different beast and the entire lifespan of a customer follows separate processes typically managed in a CRM solution.
An interesting aspect is that that these domains are relatable. For example, you can start looking at relationships between brands and products or products and customers.
There is much more to it. At any rate, the point I’ve been making in this series is that there is another way to look at PIM. Note that this is not theory - the inner nature of marketing in retail is demanding it to satisfy the increasing requirements of a successful customer experience (CX) strategy. Let's take a closer look at it.

Digital Marketing

In 2009 Adobe acquired Omniture, which now functions as Adobe Analytics and it is at the core of Adobe’s digital marketing solution. This event marked the beginning of a ‘marketing war’ that prompted the likes of IBM, Salesforce, HP, Oracle, and many others to build up an “integrated marketing cloud” platform (or “marketing hub” as defined by Gartner) in order to allow retailers to market across different channels, engaging customers on social, and using analytics to be more efficient in their targeting.

Gartner defines “digital marketing hub” as follows:

A digital marketing hub provides marketers and applications with standardized access to audience profile data, content, workflow elements, messaging and common analytic functions for orchestrating and optimizing multichannel campaigns, conversations, experiences, and data collection across online and offline channels, both manually and programmatically.

It typically includes a bundle of native marketing applications and capabilities, but it is extensible through published services with which certified partners can integrate.

No marketing hub vendors have strategically thought of integrating PIM in their platform. Actually, only Adobe has integrated with Agility Multichannel, but it seems more a tactical move. At any rate, let's see how this will unfold...I predict that it is not an isolated case.

But this is exactly the point! Whether or not fully integrated in a marketing hub, PIM is a first citizen!

The diagram below is the way I visualise the world PIM belongs to. It segments the “marketing hub” in four quadrants overlaid by concentric circles to indicate the increasing maturity levels of the hub. At the core, though, lies the customer experience. Nothing is done if it is not directed to create a customer experience that engages, bonds, and spread.

This is the next wave of PIM, which does not supersede or cannibalize the existing approaches to PIM. It is already happening but it is not mainstream yet but PIM will soon be seen more and more in marketing hub solutions. The new, emerging , content-centric and cloud-based PIMs are the ones with this edge.

What's the next wave of PIM? Part 3

noreply@blogger.com (Michele Arpaia) — Sun, 01 May 2016 07:59:00 +0000

This is the third instalment of the series about the present and future of PIM. Readers are invited to take a look at the previous posts (here, here) and the interlude about the interplay of content and data.

PIM as a content and publishing platform

Longtime readers will be familiar with my approach to PIM. In short, PIM is a discipline, or at least the fundamental tenets of PIM are dictated by how businesses operate to bring products they sell to life, and not by technology vendors (that’s why it is a discipline). As such, it is a discipline that ties in a number of processes such as product introduction, product lifecycle management, supplier collaboration, customer conversion, etc. (being a discipline is a beautiful thing because it springboards innovation (but this is a different story…). Now, and this is the crux of the matter, to mature a product into a state where it can be sold across multiple customer touch points requires a systematic approach to developing and curating relevant and useful product content to make products part of the overall buying experience.
A few examples will exemplify this point.

Let’s take a look at Nike website which shows some interesting ideas though not all of them are fully realized. First off, I was looking for men’s shoes and I landed on “Nike Air Huarache”, which is the name of the style.
Defining a Style as a template is an important first step to create a container that will be filled with content. Each style has multiple variations. In fact, you can select the color of your shoes from within the “style” page (hint: take a look at the style number pattern on the page).
Images, description, benefits, more technical specification, is structured content not data. In addition, reviews are an important piece of content externally created and attached to products!

Another important feature is the management of collections. Again, a collection is a container of products for a specific purpose i.e. defining a theme. For example, “Limited Release”, or “Nike Air”, are collections of products to fulfill a specific purpose. Ideally, there would be content curated ad hoc for a collection, such as a video to engage consumers in the purpose of the collection. Also, products in the collection may have additional content attached to them on top of the standard product content. Eventually, you may want a collection to be a unit that can be measured against a revenue forecast.

Finally, Nike also sports the concept of “launch calendar”. Cool idea to create addiction to the brand. Shoes that are not still available for sales, can be marketed. A product content platform would allow to make the information about future products already available. This feature is not fully realized by Nike but the idea is nice.

These are just a few examples of how a proper content platform enables creatives and marketers to increase customer experience. By the way, Nike should improve some processes to better handle their product content ;-)

Obviously, PIM is more than that. Imagine to localize that content, to create product content specific for markets. Or to publish content on the increasing number of marketplaces that have their own “template” to publish products e.g. attributes, taxonomies, etc.

Without PIM all this would be the worst nightmare ever for brand marketers and retailers.

An holistic view
Slicing the PIM market is not an easy feat and the risk of oversimplification is real. However, there is a trend that I spotted. This space does not permit to deeply elaborate on this trend but a few strokes will do the trick ;-)

Typically, traditional vendors tend to target big businesses which generally suffer from a lots of data pains. Legacy is the enemy of these businesses so the top priority is to setup governance around the fundamental data domains such as product. In this scenario, a solid MDM/PIM is what you need. It also helps to fix the problem at the upstream of their value chain e.g. supplier collaboration.

Another family of PIM vendors are characterized by an interesting mix of data governance, content management (often not very sophisticated though), and a good and in some cases great end-to-end process coverage i.e. from product ranging in collaboration with suppliers, category management, content authoring, to product catalogue syndication across various channels. Their target market is still big business with notable exceptions. Often, traditional vendors that have embarked on a road map for innovation, land on this hybrid land.

Emerging PIM vendors are just that. They have the luxury to learn from what has happend in this space over the last decade. They position their PIM in the 'content marketing' context. They are focused on specific industries such as food, apparel, department stores, etc. basically, they are great at some use cases. As a result their solution is simpler. They inherently have the ability to live in broader ecosystems. These PIMs are seen as 'content machines' to feed marketplaces, websites, portals, etc. Creatives, marketers, and publishers just love them.
In the next and final installment of this series, I will expand on some key aspects of this brand of PIM.

In the meantime, I tried to 'draw up' some of my scribbles that resulted in the following diagram, which I like to believe is self-explanatory :-)

Use-case driven PIM vendor market segmentation

Interlude - the interplay of data and content

noreply@blogger.com (Michele Arpaia) — Fri, 15 Apr 2016 05:52:00 +0000

In my last post I proposed to see PIM from at least two distinct standpoints. The first is the traditional view of PIM as part of the broader MDM family. The second, I argue, is an emerging trend that see PIM as an element of a broader marketing platform. This will be part of a forthcoming white paper I am working on for HubDesigns.

For the time being, I thought it would make sense to spell out a few things about data and content to help understand the point I made in the previous post. This is an interlude between the previous posts on this topic and the next one that will conclude the series.

Remember, PIM as "an MDM use case", to cite Andrew White, tends to be engineered around data optimization, while PIM as a "Content Management use case", tends to satisfy the appetite of marketers (details are here and here).

Data and Content

Data is the mechanism to 'register' what happens in the world. This can take various forms. For instance, the shirt you bought yesterday is a piece of data. The relationship between you and your partner is another piece of data. The properties of your Canon camera are pieces of data. And so on and so forth.

A helpful analogy is to compare data and everything that revolves around it such as governance, quality, fit for purpose, accuracy, etc. with the plumbing systems of your house along with doors, windows, walls, electricity, etc. In short, all the spec that architects and builders laid out when the house was conceived.

Content, on the other hand, is what brings communications alive. It is information in context that can be communicated to other human beings to entertain, persuade, educate, or sell. I recently published a post on LinkedIn regarding the convergence of creativity and marketing. In that piece, I defined content as

...information that is made relevant by context, that is ready to be packaged and potentially relate-able to other content, and deliverable anytime, anywhere.

To extend the analogy of the house, content is what takes place in the house. Conversations, cooking, dinners, party with friends, etc. It is what human beings create and communicate with the means at their disposal.

In the next and final instalment of this series, I will summarize the key points of differentiation between the two species of PIM. There are solid use cases for both. It all depends on (alas, my consultant hat keeps coming back ;-) the type of pains affecting the trust and loyalty of your customers.

What's the next wave of PIM? Part 2

noreply@blogger.com (Michele Arpaia) — Thu, 25 Feb 2016 23:04:00 +0000

In the previous post, I offered a view to look at the PIM marketplace. From retailers and manufactories perspective, PIM has become a necessity to meet fast paced customer demands. The vendor marketplace, on the other hand, is getting crowded to meet the increasing demand. In that post, I also provided a few criteria to make sense of different vendor offers.

In this installment and the next, I intend to articulate a further criterion, or a standpoint to look at the PIM market. Let me first summarize what we have so far:

Some PIM vendors are traditional, some emerging, some disruptive (less than a handful)
Vendors tend to primarily focus on one target company size, i.e. enterprise, medium, and small companies
Finally, a practical way to group vendors is by the kind of use cases they are primarily designed for, e.g. emphasis on buying or selling side processes, marketing content, merchandising support, channels, etc.

From (1) one deduces that the market has been increasingly demanding PIM, at least for over a decade now, from (2) that PIM is (no longer) a need for a niche, and from (3) that there are various business areas that PIM can address but every and each vendor has designed their own solution with a clear (set of) predominant use case(s) in mind.

The last point offers a nice introduction to a fourth standpoint to which we now turn.

Historically, PIM and CDI (Customer Data Integration) predate MDM. In fact, MDM has common roots in two different parts of the business: how to achieve an holistic and semantically consistent view of product, and customer. Andrew White, the Gartner analyst, once put it clearly: “you can tell about where a vendor comes from by the way they talk about MDM’s history. Too many relate MDM to CDI only, as if that were the source. Too few related MDM to PIM only. The reality is that both are parts of MDM’s history. As PIM and CDI, these two technologies did start at different times, and in different industries, but they are part of MDM.”

While this is historically accurate, in my opinion, it does not capture how PIM has evolved in some quarters. But it is fair to say that a good chunk of the market is represented by what Mr. White says. Tom Marine over b2x Partners used the Family/Genius/Species analogy which is quite fitting as well (except for a couple of vendors which are of a different species ;-)). The point of the matter is that a good number of vendors come from this heritage and it is easy to identify them by name or by the way they emphasize two important things:

The role of data as an asset
Relationship between domains e.g. Customer, Suppliers, Products, etc.

A second species of PIM seems to lean towards a platform that is primarily a business application to serve the needs of marketing and sales departments. These vendors pay little emphasis on the role of data, or the importance of product hubs, quality of data, etc. – by no means essential elements – but stress the importance of having a product content platform to easily, collaboratively, and visually aggregate and organize (product) structured and unstructured content to be consumed inside and outside the organization.

Confused? Should you not! We will explore this new family of PIMs in the next installment.

For now, let me offer two simple considerations:

1. PIM belongs to at least two solution spaces i.e. MDM and Content Management (please note: I am not confusing PIM and Content Management here). Among other things, this means the choice of the right PIM is strongly driven by demand i.e. what use cases fit your problem

2. The interesting and sometime misleading debate over whether MDM and PIM are separate, or need to be married, etc. (for example, see here and here for an overview, while here, here, to see some interesting pro and against arguments) is squarely in the MDM family camp and it is easy now to see how to resolve the conundrum (this is left as the dreaded exercise for the reader :-)). On the other hand, this debate is utterly irrelevant in the Content Management camp. Thank you God!

Stay tuned.

A brief history of retailing

noreply@blogger.com (Michele Arpaia) — Wed, 23 Dec 2015 09:15:00 +0000




Loading...

What's the next wave of PIM? Part I.

noreply@blogger.com (Michele Arpaia) — Sun, 31 May 2015 10:26:00 +0000

The PIM market stands on the cusp of a turning point, almost a transition to a ‘phase 2’ (very tempted to call it “PIM 2.0”…) While most still can’t see how the investment in a proper PIM solution will pay a lot of dividends, there is also every sign that the market is on the verge of a significant turn.

The signs come from two directions, namely, retailers and (PIM) vendors. The former beams bright signs; from the latter the signs are dim but encouraging.

Let me explain.

Fast-faced economy and game-changing technologies such as mobile’s have shifted the balance of power, now tilting away from retailers and toward consumers. Invariably, while the core functions of retail are – and will always be – unchanged, business models are being redefined by experimenting new ways of delivering value. Nordstrom offers a mobile app that enables the user not only to browse, read customer reviews, etc. but to check product availability at nearby stores. Macy's, Levis, Target, are using beacons to entice people into their stores. And countless examples could be shown. What’s the common denominator from the retailer standpoint? It is this: nimbly responding to customer needs or anticipating buying habits. But if they don’t have processes in place to quickly introduce new products or variations of existing products to channels, with the appropriate and relevant content, they will lose the opportunity to have an edge over their competitors.

As a result, retailers are demanding – wittingly or not, it doesn’t really matter – product information management (PIM) discipline to be in place. I am not naïve, I am aware that PIM has been around for more than a decade, but it is now being recognised as a necessity and no longer a luxury. And that brings me at once to the second point, namely, the market seen from PIM vendors’ standpoint.

PIM, as a discipline, is a solid body of knowledge but it is variedly embodied in software platforms found in the market. I personally segment this market along many dimensions. For example, there are vendors which I call ‘traditional’, some are disruptive, and many are emerging (yes, some overlap is conceded). A second dimension could be the market they serve, such as enterprise, mid-sized businesses, and small businesses (again, allowing for overlaps). A third dimension, and actually a very important one, is the use cases they are designed for. For example, there are PIMs that put more emphasis on the buying side of the value chain, others are more marketing-oriented, others lean towards product lifecycle, others towards merchandising, others towards ecommerce, etc. So no Swiss knifes in the PIM market ;-)

The combined force from retailers and vendors is bringing about a re-evaluation of what PIM really is (and not just a product hub to centralise data) and how to use it. To be precise, the real force is the empowered customer who is pressing retailers and consequently giving PIM new life blood.

Admittedly, this is only a small aspect of what has changed in retail but I submit a very important one for a simple reason. Retailers’ raison d'être is to serve customers with relevant products. I believe PIM is the key to resolving half of this equation.

In the next installment I will explore ways to move from the hub-centric view of PIM.

The Colours of PIM

noreply@blogger.com (Michele Arpaia) — Mon, 19 Jan 2015 10:20:00 +0000

I am borrowing the simple “Six Hats” concept advanced by Edward de Bono to exemplify the discipline of Product Information Management (PIM) in a creative manner. Given that I am also tired of seeing PIM defined, purported, marketed and trumpeted in the same way in many quarters i.e. a repository of product data to bla bla bla, I will sprinkle a few insights I am working on to really start looking at PIM from a new and more adequate angle.

Now, de Bono's method aims to force us to move outside our habitual thinking style to get a more rounded view of a situation.

He effectively uses six colours to describe six different angles (hats) to see a situation. As you can imagine, this has nothing to do with PIM but the intuitive meaning attributed to colours offers a nice way to look at six key constituents of PIM.

Let’s put the PIM hats on!

This is the traditional way of understanding PIM as a repository of product data. It is a paramount foundation upon which anything else is built.

Think of feelings. Think of warmth. PIM gives the opportunity to turn raw data into something you can relate to. Imagine the compulsive and non-rational purchase act customers often perform when presented with stories around products curated with a relevant script and touching pictures and/or videos.

Black is the colour of critical thinking which translates into a rigorous search for efficiency. The PIM black hat points out how something does not fit the resources and fix it. In fact, PIM maximizes the impact on costs by streamlining the production of products.

Think of value. Think of optimism. This is the colour of the benefits delivered to customers and the revenue growth coming out of this mutual relationship. This is where PIM shines :-) in bringing about growth and expansion.

Think of vegetation. Think of new leaves and branches. Under the green hat we put forward new ideas e.g. how to sell products across multiple touch points, how to extend product range across multiple segments, how to appeal to key suppliers, etc.

Think of the blue sky. Think of 'overview'. Think of big picture. The blue hat is like a conductor of the orchestra. PIM is like the ringmaster of a circus who manages the performance, introduces the various tasks in the value chain (e.g. drop shipping), and guide the users through the entertainment experience :-)

It may seem a bit of a stretch but it was funny writing about it. Any colour you'd like to add?

Featured on Which-50

noreply@blogger.com (Michele Arpaia) — Wed, 14 Jan 2015 06:16:00 +0000

I am glad to inform you that two of my articles about the importance of business processes over data have been combined in one piece and published on Which-50, a digital intelligence business publisher for C-Suite executives, strategists, founders and directors.

Hopefully the beginning of a fruitful collaboration.

Round up!

noreply@blogger.com (Michele Arpaia) — Wed, 31 Dec 2014 04:37:00 +0000

For readers who might be interested, I thought it would be useful to gather together in one place links to various posts on Omnichannel and customer-centricity.

On to the posts.

Enjoy!