The Challenge

the challenge 2

The challenges faced by Louis-Vijay Dupont (LVD) to implement the Arts Exchange vision will illustrate common challenges faced by any enterprise, which depends on deploying business services to support business capabilities.

A problem which help is needed to solve

An enterprise starts with a motive.

Louis-Vijay Dupont (LVD) is a successful entrepreneur. In the past, he has started successful ventures in retail, small finance and social media. With his acquired fortune, he has acquired a modest, but very beautiful estate, and in the process of furnishing and decorating it, he has become interested in the arts. It struck him how difficult it was to discover this new domain.

With the development of internet platforms, music performers have been able to advertise themselves directly to the general public, and acquire a following independently from the major industry labels. Once known, they can negotiate with said labels or start their ow

But there is no similar path for artists who work in physical media (painters, ceramicists, sculptors, various crafts). They are still limited to local shops or to galleries. Their work, if known at all, is known only to critics who have encountered them almost at random.

LVD has decided this must change.

Vision & Mission

He has a Vision – A cool, safe and easy to use web arts forum to be accessed by artists, critics and amateurs.

This enterprise has the following Mission – In partnership with the art community, provide means for artists, critics and amateurs to interact and share content and knowledge for the benefit of people involved or trying to get involved with arts.

  • artists to show their work in a secure manner;
  • amateurs to browse, study and express their views;
  • critics to present reasoned opinions;
  • mentoring relationships to emerge and flourish; and
  • sales can be brokered in a “fair-trade” manner.

A Strategy

And he has developed a Strategy – his enterprise will leverage the wealth of existing social media to support the new objectives, thereby reducing the overhead and the time to market.

A Quick Fix

So he has gone in a quest to find someone who could pull together the required technical resources and assemble the platform to support his new community. He has found a freelance wizard, Al, who agreed to take on the job. Al assembles a prototype platform very quickly.

Wishful Thinking

LVD plays with the prototype and is quite pleased; this is exactly what he wanted all along: he is happy. It looks like he will soon be in business. He starts to show his new baby to his friends, and decides to test it with the help of real art people (all those people LVD has met while decorating his estate).

Adaptation: Context and Model

Unfortunately, Al is not very knowledgeable in the world of art. When those real art people test the prototype, it is found wanting. “That is not the way we do things”. And the fact is: the Community will take off only if its potential members feel comfortable with the platform from the very start. There is only one chance to establish the image, the “brand”. If that fails, artists, critics and amateurs will ignore it in droves.

Whatever Al designed and prototyped will of course operate according to its own design, and may not be adapted to our particular kind of users. What we need is a specific model for our operations. And this means we must specify more detail. Otherwise, LVD and Al may spend time and money building prototypes at random, trying to find one that satisfies the real users.

Implementation

Then there arises another serious issue: a prototype is not enough. We need to implement the full system. And this task has three major characteristics: it is error-prone, it is slow and it is costly. The major reason why the implementation process is prone to errors is that the initial drawing – design – does not indicate all we need to make the system real.

As the dialogue between Al and LVD shows, several pesky obstacles arise. On the one hand, Al is – self-avowedly – rather awkward at art things. On the other hand, LVD invests a lot of imagination in his evaluation of the prototypes.

Iteration

The number of iterations required to reach even this clumsy agreement is the major reason for the other two attributes of implementation: multiple attempts make the process slow, and consequently costly.

Change

But wait: there is more… In his imagination of the future community system, LVD was thinking of a few art people he knows. But one day at a party he meets a completely new crowd. And he realises that their idea of a congenial environment sounds quite different than the one he and Al have been aiming for.

These new people are quite interesting: he wants to cultivate them, attract them to his community. But he realises that if they see his baby in its current form, they will spread negative views about it, and not only stay away, but dissuade other art people as well.

All of a sudden he has encountered a serious threat. He must act quickly.

 Responsiveness

Unfortunately, the process of implementing a response to this new situation (opportunity or threat, the same would apply) is slow (and costly and error-prone, yes). So the disaster (bad publicity for his baby) may strike long before he has an alternative. He really needs an on-demand Art Crowd Discriminator. And he needs to get it right the first time.

Right The First Time

LVD thinks: there must be a way to ensure production of the correct solution “by the book”:

  • If we get our model right, we might be able to set down a set of procedures to create the implementation in a sure-fire way. So we can reduce error if we have well-defined processes to go from the model to the real thing.
  • Before we can apply these processes, we must make sure the model is right: we need means to test it. Ideally, we would simulate the whole operation on the model. For this we need sophisticated simulation tools.

LVD has figured out the Holy Grail of system designers – the Model-Driven approach to system engineering.[1]

Metamodels (Repeatability + Automation)

But of course, LVD realises, he does not have a model of his enterprise to begin with. Surely a model to support this Model-Driven approach must be more than his vision and his imaginative musings.

To make it possible to specify a model sufficiently well, we must first know what is to be in the model. And this is where our concept of an ideal world encounters its major obstacle: few people know how to model an enterprise. We need a metamodel, that is, a model of what a model should be.

In some kinds of engineering, such as for automobiles, we have by now a pretty thorough understanding of the necessary components, how they interact with each other, and other characteristics. So we can model an automobile quite accurately – and we can also simulate its operation.

In other areas, our models are quite firm, and generally usable, but there are several flavours of them, according to nationality, culture, religion or corporate affiliation. Very often, there is poor agreement on what is relevant to model – in other words, the metamodels are not mutually compatible, so that knowledge expressed in one of them cannot be reused in another.

Finally, there are many domains of human endeavour where we don’t even have sufficiently explicit, or sufficiently detailed views on what a model should be.

Our knowledge regarding the dynamics of Enterprises is somewhere between the second and third cases. There are many models of various aspects of Enterprises, but they are not unified into a general theory which would support a stable metamodel.

LVD figures that a part model is better than no model – we must do the best we can to construct a precise model of the parts we understand.

Setting the Landscape. The partial model…

[1] Recently some standards organisations have committed themselves to endeavours in this domain. On the whole, the OMG’s Model-driven Architecture (MDA) initiative is more narrowly focused on IT systems. But there is no reason to limit our aspirations to IT. If we can specify a model sufficiently well, we can simulate its operation. If we can specify procedures to implement it, we can in principle guarantee its operation.

Leave a Reply

Your email address will not be published. Required fields are marked *