The Restaurant at the End of the Internet

Coherent modelling landscapes

2009-06-20T07:13:00.003-07:00

The role of models in enterprise transformation
My previous blog was concerned with securing modelling effort. A specific aspect in this regard is the coherence of models. As promised, I will now elaborate on the coherence of models. Before reading this blog, it therefore makes sense to first read the previous one, where I also argue how enterprise transformation is a model-intensive activity, and why it therefore makes sense to secure modelling efforts.

The set of models produced during an enterprise transformation cover the entire chain of a transformation, ranging from models used for problem analysis, via architecture models, to specific designs. While these models clearly deal with different aspects of the enterprise, and are concerned with different stages during the transformation, they still deal with the same domain. Therefore, it is only natural to expect these models to have a strong coherence. Such an increased coherence would, for example, enable the re-use of investments made in models earlier on in a transformation process (or previous transformation processes!).

Coherence between models
Currently, models produced during one stage of the transformation process (such as an ArchiMate model) quite often have to be re-drawn, or even re-modelled, in some other language in a later stage of the process (such as a BPMN or a UML model). This leads to unnecessary delays and costs during a transformation process, and basicially constitutes a major disinvestment.

The coherence (and automatic transformations) between different models is hampered due to the inherent disconnectedness of the modelling languages used, such as BPMN, UML, ArchiMate, et cetera. With "inherent disconnectedness" I refer to the fact that the meta-models underlying these languages have (from their designs) no formal connections. At the same, time an actor used in e.g. an ArchiMate model will re-appear as an actor in a BPMN model, while this latter model may also provide more details of the business process used in the original ArchiMate model. Of course it is possible to provide a mapping from (relavant parts of) an ArchiMate model to a BPMN model. However:

A better integration of the meta-models would make such transformations more easy. A BPMN model provides a detailed view of the actual process and the roles of the actors involved, than what an ArchiMate model would. Therefore, one would expect the BPMN meta-model to be a specialisation of (part of) the ArchiMate meta-model as well. Regretfully, this is not the case at present, but might be strived for by the standardisation bodies.
Even more, the needed transformations between e.g. (a relevant part of) an ArchiMate model towards/backwards a BPMN model could we standardised and become part of the body of standards (e.g. supporting boundaryless information flow at the level of models). This would ensure the portability of these transformations between different modelling tools in use by organisations.

Both of these require an active role of the standardisation organisations such as the OMG and The Open Group, as well as their core members to take their responsibility in this.

An even more universal modelling language?
You might argue that the problem of coherence between models can be solved easily by creating one integrated modelling language.

Essentially UML already provides such a language focusing at the level of software applications and their direct usage environment, while ArchiMate provides such a language focussed at the representation of enterprise architectures over different levels of abstraction (from technology via applications to the business level). The operative word here is "focussed". When designing a modelling language, one selects different modelling constructs to express the models. As argued in two earlier papers (1, 2), the modelling concepts included in a modelling language should really provide a real utility in relation to the purpose/focus of the language.

Depending on the stage of an enterprise transformation, the aspects of the enterprise one focusses on, etc, different sets of modelling concepts are necessary. Therefore, a single unified modelling language will be hard to create, and even harder to use. In that sense we are likely to end up with several more focussed languages, with their own added value

At the same time, this does not have to mean that we cannot have coherence between the different models. For example, within a single enterprise transformation, one may use:

e3Value to model the position of the enterprise in a value web,
DEMO to elaborate the essential transactions between the enterprise and its environment as well as the essential internal workings of the enterprise,
ArchiMate to elaborate the enterprise architecture towards IT support for the enterprise's activities and
BPMN and UML to refine things even further to the level of specific applications and business processes.

These are all valid reasons for using the distinctive modelling languages. At the same time, it is only fair to expect to be able to trace the relations between:

value exchanges between the enterprise and other actors in a value web (e3Value),
the transactions between these actors operationalising these value exchanges and the essential processed needed to realise them (DEMO),
the implementation of these essentual transactions and processes in terms of tangible actors, applications and IT, in terms of an enterprise architecture (ArchiMate),
the actual realisation of these artefacts in applications and business processes (BPMN and UML).

In other words, a coherent modelling landscape is called for. To really be able to do so, requires these models to be interrelated, and eventually, the meta-models of the underlying modelling languages. The most basic way of realising this is to at least use persistant naming of actors, processes, etc, accross the different models. However, to explicitly express the fact that a specific value exchange (e3Value) is implemented using a number of transactions (DEMO), requires additional relations matching the two meta-models.

Realising a modelling landscape
The most practical way to proceed at the moment would be to apply a disciplined naming convention for the concepts used. A practical way of doing this would be the use of a domain model of the different domain concepts used accross the specific e3Value, DEMO, ArchiMate, etc, models, and a consequent use of the (names of these) concepts accross the models. Actually, creating such a domain model may also help modellers in the creation of more specific models such as value models and process models, since they can then start from a thorough understanding of the domain. Some of these basic ideas are discussed in two earlier papers (3
and 4).

A more ambitious approach would also require more advanced modelling tools, in which meta-models of different modelling languages are positioned in a hierarchy in such a way that models can also be mutually related and essentially be re-interpreted in terms of more specific meta-models. In the past, dome some initial work has been done in this regard (see 5 and 6). Such a more ambituous approach would also require a more active role of the standardisation organisations such as the OMG and The Open Group.

Securing modelling effort

2009-06-20T02:14:00.000-07:00

The role of models in enterprise transformations
When enterprises aim to meet new challenges, or optimise themselves in terms of increased flexibility, effectiveness, or efficiency, they will transform themselves. In other words, they will engage themselves in a deliberate change. This may involve changes to several aspects, including organisational structures, their processes, their culture, as well as their IT systems.

In my view, such transformations will become increasingly model intensive in the sense that the driving process of (continuously!) assessing what to change, selecting the desired direction of a change, and consequently acting out the change, involves models in different roles (see one of my earlier blogs). On the one hand, the increase of the use of models is driven by the increasing role of IT as an integral part of business operations, bringing the model-intensive nature of IT development to enterprise transformation. On the other hand, the transformation of "the business" itself becomes model-intensive as well, due to business process management, compliance regulations, etc. Even more, within the organisational sciences, models play an (increasingly) important role as well in terms of problem structuring, system dynamics, et cetera.

Within fields such as enterprise architecture, a distinction is made between models and views. Within the context of this blog, however, I will not necessarily make such a distinction, since both can be regarded as models in a broader sense. Furthermore, sets of business rules and sets of architecture principles can be regarded as models as well, so we are not just talking about models of a diagramatic or graphical nature.

The models used during enterprise transformations range from high level architectural models, which have normative role towards lower levels of architectures, to the more detailed models used within change projects, which may involve business rules, business process models, and even highly formalised models that can be executed, interpreted, or compiled directly by computers. In other words, the models may range from informal sketches to models with a more explicit and formal syntax, to models with a mathematically well defined semantics.

Return on modelling effort
A lot of time and effort is put in the creation of these models. In other words, these models represent a large investment to enterprises. In making these investments, it is sensible to guard a proper return on modelling effort. As discussed in an older blog on return on modelling effort, some potential returns on investments for example are:

Models may provide insight. Either directly or indirectly by deriving views from the models that answer specific questions. This insight might be needed towards an informing purpose, a decision making purpose, analytical purpose, etc.
Models may provide guidance towards the execution of work. This could be design activities, the operational execution of work, etc.
Models can act as a formal a steering/regulation instrument.
They can act as a common frame of reference, i.e. an ontology.
They can be directly executable or at least formally interpretable (MDS and MDA!).

Securing modelling effort
The possible returns of modelling effort will not always (need to) yield their returns immediately after the modelling effort. In general, the returns may (also) follow at a later stage. This does stress the importance to secure the investments made in terms of these models, in order to guard their potential returns. In practice, however, these investments are treated rather badly. For example:

models are not kept up-to-date without making conscious decision to disinvest in the actuality of the model,
models produced during one stage of the transformation process (such as an ArchiMate model) quite often have to be re-drawn or even re-modelled in some other language in a later stage of the process (such as a BPMN model or UML model).

Securing modelling efforts will involve several aspects. Some of them could include:

Guard the actuality of models - The actuality of models can be validated by using mining techniques. For example, logs from work flow systems and ERP systems can be used to continuously (and automatically!) evaluate the validity of business process models (see e.g. process mining). Another example would be the use of logs from an enterprise service bus to monitor which software components depent on each other and see if reality complies to the "theoretical" perspective at the architecture level.
Model management - Models with a remaining return on modelling effort should be well managed. This can be done using repositories. However, this should not just pertain to the models themselves, but also involve a report on the context and intent for wich the models were created. At the same, time we should be aware that there are several models that can be discarded because they have served their purpose, e.g. because they were only intended to align people's focus, or to express an intermediate idea.
Coherence of models - Separate from the fact that it is necessary to remain a strong focus on a return on modelling effort, there is also a lot to be gained from a better integration between the different models produced during modelling. These models range cover the entire chain of transformations, ranging from models used for problem analysis, via architecture models, to specific designs. While these models clearly deal with different aspects of the enterprise, and are concerned with different stages during the transformation, they still deal with the same domain. Therefore it would only be natural for these models to have a stronger coherence. Such an increased coherence would, for example, enable the re-use of investments made in models earlier on in a transformation process. Currently this is hampered by the disconnectedness of the modelling languages used, such as BPMN, UML, ArchiMate, et cetera.

In a future blog I intend to elaborate more on the latter issue of coherence of models.

Life as a service; The cloud as my PA

2009-05-22T08:33:00.000-07:00

In my previous blog I starting comparing Zen and enterprise architecture. I will definitely continue this stream in weeks to come. However, a recent comment on twitter concerning "Integration as a Service" triggered some dormant desires on a closer integration of services, that would truly support my life as an individual. At the moment, however, we suffer from scattered devices, scattered interfaces and scattered data. Let me elaborate.

Scattered devices

A few months ago, Microsoft's Steve Balmer stated that our PC Is Just One of Three Screens. More specifically:

Now it's no longer just about the desktop but really a broader vision," Ballmer said, adding later: "Microsoft is transforming what Windows is, from a PC OS to a connected platform; an experience that spans the PC, the phone, the TV and the cloud."

This certainly is what one would expect in the age of cloud computing. As a Mac user I'll forgive him the reference to a PC rather than a Mac. However, I wonder how well Steve (Ballmer) can count. If I count the devices I'd like to see connected, it doesn't stop at three. Separate from a discussion on a sensor network, I count the following devices I use to interact with:

My Macbook Air.
My iMac desktop.
An iPod touch (plus Nike+ sensor).
A dual sim mobile phone.
My home phone.
Some company supplied black Visa box I need to sync my cloud agenda to the company's agenda.
Apple TV.
iPod music/audio-book system in my car.
A Tom Tom in my car.
Guest usage of someone else's Mac/PC/Kiosk/Screen/AppleTV to access my stuff in the cloud.

That's (at least!) ten, not three. As you can easily imagine it makes a lot of sense to have these devices operate like an integrated whole. However, I think integration is a too limited goal here. I think we should be more ambitious. Based on a abstract perspective I've shared earlier (ActorWeb), I would like to argue that these devices should primarily be regarded as interfaces to a personal assistant (PA) in the cloud (possibly with their own computational power to remain operating when disconnected in a swarm like style).

Is it such an extreme thing to expect to be able to plan my car journey on my AppleTV attached to the big screen in my room, while the addresses I need to visit are picket out of my agenda in the cloud, and the route is automatically available in my car's Tom Tom in the morning? Guess it is ... especially when big vendors can't count beyond three.

Scattered interfaces

What have SMS, E-Mail, Phone, Skype, Twitter, etc, in common? They are all forms of communication. Some have a "broadcast" nature (Twitter), some have a synchronous nature (Chat or Phone), some have an asynchronous nature (SMS, E-Mail, Voice Mail). But they are all forms of communication. We all experience how we have different ID's for e-mail, chat, Skype, phone numbers etc. Sometimes this makes sense as it allows us to separate between different roles and levels of anonymity, but usually the different ID's are really due to the different interfaces. I would like to argue that in the age of cloud computing this is old-world thinking. I can't wait until we indeed have true unified messaging with a single inbox and outbox under a single ID, only differentiated based on different roles (and levels of anonymity) I, as a person, like to introduce.

However, it is not just about integrated messaging. My agenda, my address book, applications I use for work, banking, et cetera, still offer scattered (and sometimes even device-type bound) interfaces. An obvious good move towards better integration of interfaces are role-based interfaces. For example, Capgemini's TechnoVision states:

Role-based user portals: they morph their content to the specific, context-dependent needs of an individual user.

Certainly a good thing, but again, I think we need to be more ambitious. I don't just need a role-based user portal. I think we need cloud-based role-specific virtual work-spaces, which we can approach using the different devices as discussed above. The cloud should offer me a personal assistant which helps me in executing my roles, while communicating to me using the different devices, making things truly role-aware and context-aware.

Scattered data

Do you do FaceBook? How about Hyves, LinkedIn, Plaxo, Trip It, Twitter, et cetera? Our address data, calendar data, profiles, employment pasts, lists of hobby's, are scattered over different services. On the one hand this constitutes a privacy challenge, but at the same time it is an absolute horror to maintain all these profiles. Based on my personal roles, I would ideally like to maintain a profile of data and classes of events I would like to share with other people. This profile can than be shared by these social websites.

Profiles for social networking websites are only an example of all the data we need to maintain on different locations. In general, I would like to maintain such data on one location and allow specific other services (e.g. a social network website, or a banking service, or a travel planning service) to access this data. At the moment I sometimes have to re-type this data (or just cut & paste if I'm lucky).

Life as a service

In the present we have to make do with scattered devices, scattered services and scattered data. Life in the digital age really requires us to find our way in a maze of services. What would be needed, I think, is:

A computing environment involving a cloud computing model amidst a swarm of devices. The devices offer sensors and interfaces towards users. They should also be able to take over some basic computing when needed. E.g. when detached from "the grid".
More open standards enabling basic interoperability in terms of unified messaging, unified calendar services, unified address book, et cetera.

Life as a service, which would really be supporting the way we life, still seems to be a long way to go. It certainly takes a bolder vision that a "3 screen vision". Maybe the other Steve is bold enough.

Enterprise architecture as organisational Zen

2009-05-17T07:57:00.000-07:00

The way I have learned to understand Zen, is that it is about concentration and focus. By means of meditation, Zen teaches us to focus on the things you really want to focus on, meanwhile allowing us to obtain insight into our inner drives as well as our imprinted reflexes. Whenever we, as average beings, are put under stress, our imprinted reflexes tend take over, taking us away from the things that really matter to us. Instead, we start worrying about how good we are in our jobs, whether our boss likes us, threats to our status in society, et cetera.

Zen helps us in focusing on what is important. It does so by improving our mental discipline by way of meditation. This improved discipline allows us, in our daily live, to be more aware of situations where our mind starts wondering off. Especially when we are put under stress, and the mental reflexes that are imprinted in our mind (based on past experiences and shadow beliefs) take over. Once we have learned to observe such behaviour, we can chose (not) to act upon it, and regain our focus. In doing so, it is also important not to judge ourselves. It's a process of learning and forgiving.

So what does Zen have to do with enterprise architecture? Well, a lot in my opinion. An enterprise architecture, as in, the architecture of the enterprise and not just enterprise-wide IT architecture, is an elaboration of the enterprise's strategy. As such, it can be regarded as an operationalisation of what the enterprise wants to focus on. Using models such as collections of architecture principles, specific design models in e.g. ArchiMate, et cetera, the enterprise's strategy is made more operational. The desired focus is elaborated, and possibly translated into a sequence of intermediary stages offering a short-term to long-term perspective.

This all sounds very nice, you might say, but in practice transformation projects are hard to keep on track with regards to the architecture. More often than not, projects are not in compliance with the focus as articulated in the enterprise architecture. There always seems to be a business driver that allows a project not to comply to the architecture. Usually due to a clash between short-term and long-term interests. Architecture governance is a difficult task indeed.

Interestingly enough tough, there is a strong parallel to the goals of Zen meditation. What does it mean if parts of an organisation allow a transformation project to produce results which are non-compliant to the enterprise architecture? Isn't the wise thing to do in such a case, to identify the discrepancy and then use it to grow as an enterprise? No blame-game, but a trigger to improve the governance needed to execute the enterprise's strategy. Does the architecture really focus on what is essential to the enterprise's strategy? Isn't the architecture too elaborate/restrictive? Is the non-compliance of projects based on a 'reflex' of the sponsors/stakeholders or are they the indication of a shift in strategy/focus? Or is it 'simply' due to a lack of discipline, and is more 'training' necessary (e.g. by means of stricter governance)?

Needless to say that the current economic crises brings about a multitude of organisational 'reflexes' leading to several responses that are not in compliance to the architecture (and strategy). Does this imply a stronger focus of the architecture on the enterprise's strategy, a shift in the enterprise's strategy, or .. is it just a panic-driven reflex? There is a lot to learn at a time of crises!

Traditionally I've viewed enterprise architecture as a means to direct enterprise transformations. I still do, but I now propose to treat non-compliance of projects not as a problem but as a way for the organisation to better understand its focus and improve its ability to stay focused on the things that matter. Enterprise architecture as organisational Zen.

Architects: Execute and evaluate your methods!

2009-04-21T05:25:00.001-07:00

Since architecture is a relative new field, much debate goes on about the methods and techniques to be used within the field. As one of the key competencies of an architects is to be able think conceptually, it is only natural for architects to engage in lengthy discussions about their tools, techniques, approaches and methods. A recent example of such a discussion can be found on the Via Nova Architectura website, where a rather opinionative posting on TOGAF 9 resulted in an involved discussion with 38 elaborate responses.

In principle, there is nothing wrong with a critical attitude towards methods. Especially in developing disciplines, one needs to be critical about the efficiency and effectiveness of the methods we apply. Regretfully, however, current discussions on architecture methods tend to be based on opinions, views and impressions rather than facts derived from thorough evaluations in practice. In the earlier mentioned discussion on TOGAF 9, several participants referred to their own (undocumented and unvalidated) private experiences. These experiences might be true and hard earned. Regretfully, however, they do not constitute a solid base for further (mature) development of the field. I would therefore like to make the case for a more scientific approach to evaluating and refining our architecture methods. This is not an easy thing to do. But is the road to maturity ever an easy road to travel?

In my opinion, we should stop discussions about architecture methods until we have conducted rigourous evaluations of these methods in practice, or at least discuss any claimed shortcomings in terms of well documented case studies observed in real life applications. For example, TOGAF, as a "purposely designed object", has an intended set of situations in which its creators will claim it to be efficient and effective in achieving certain goals. The questions to be evaluated then are: Is the method efficient and effective in achieving these goals? Are the goals relevant? Can the method be improved any further?

So rather than debating on the quality of TOGAF 9, say, I think we should focus on using our architecture methods in practice, and debate about rigourous methods to evaluate their efficiency and effectiveness in achieving results. To some architects, this may come as an unwanted call for more rigour in our field, as it may result in less heroism and folklore. An earlier call made on architects by Ron Tolido and myself to stop discussing architecture methods, but rather to get on in applying them, resulted in an even more heated debate.

Mind you. I am arguing the case for the evaluation of methods based on experiences in practice, and not the a desk-research based comparison of methods based on features that can be found in their descriptions. In the past, ample desk research has been conducted using elaborate classification frameworks in terms of their scope, viewpoints, intent, description, etc. Rather than doing more classification work, I propose we should focus on an evaluation of their practical usage. Our focus should really be on applying methods in real life situations, and evaluating these engagements in order to further improve our methods. Practical application and rigourous evaluation is key here.

Methods typically contain a description of how to "do the work". A method "to achieve X" usually contains a description of the activities and ordering on how to indeed achieve X. This set of activities, and its ordering, is quite often referred to as the method's way of working. This, nevertheless, does not necessarily mean that the way of working should be a fully elaborated recipe that will apply to all situations. A method is likely to starts its life as a method aimed at achieving goals in specific contexts. A method as a "purposely designed object", however, typically aims to be applicable in a wider range of situations. This requires the way of working as suggested by the method, to evolve into a kind of a body of actionable knowledge. In other words, a "theory for getting things done to achieve X" rather than a recipe applicable to one situation only. Quite often, the notion of method is equated to a "recipe based" way of working only. I refer to this as a "method in the narrow sense", where a method taking a wider perspective involving a "theory on getting things done" would be a "method in the broader sense". The latter requires a stronger focus on core operating principles as well as heuristics on how to make things work in specific situations. Methods can quite well start their life as a method in the narrow sense, while evolving to become a method in the broader sense. This, obviously, requires several re-design and re-factoring steps, combined with application in practice and rigourous evaluation.

In the Name of the Rose; A personal challenge

2009-02-28T12:11:00.000-08:00

When looking back on my blog entries over the past two months, you might notice that some have a more theoretical nature, while others have a more practical and/or societal nature. This mix reflects my dual role in industry and academia. I've been discussing this with some people. An obvious strategy would be to move the more theoretical entries to a separate blog. After some reflection I decided that I really shouldn't do so, but rather ensure I present the more theoretical topics in a way that is appealing to a wider audience.

Actually, I consider this to be one of my personal challenges. As discussed in one of my previous postings, I think we should move to towards slow science. I think part of that should include more the communication of scientific ideas to a wider audience, e.g. in terms of blogs,. I feel dearly about the scientific topics I have blogged about earlier. I think these topics deserve a fundamental approach. At the same time, the relevance of these topics to the field of enterprise architecture and enterprise engineering is so profound that it is important to widen the discussions. Achieving this, as a scientist, practitioner and blogger, is my personal challenge.

What inspired me in this challenge is the character of William of Baskerville, in The Name of the Rose. About 9 years ago I was getting some career advice from a colleague. One of the exercises he took me through was to mention some key movie characters I particularly liked. If I remember correctly, then I listed:

William of Baskerville, in The Name of the Rose, because of his combination of academic pursuit and practical application in solving problems.
Dian Fossey, in Gorilla's in the Mist, because of her dedication to her ideals. Giving up her comfortable life in "the west" to follow her inner drive.
James T. Kirk, in StarTrek Enterprise, because of his adventurous spirit and the fact that he prefers a position as ship's captain over the role of an admiral. Better to be "out there" than to linger behind a desk.
Indiana Jones, because of his adventurous spirit and ingenuity in the field.

To me, the character of William of Baskerville is really exemplary to finding a balance between scholarly achievement and practical application. People who know me personally might recognise some of reasons for selecting the other characters. Maybe I'll be tempted into discussing the other ones as personal challenges in future blog entries as well.

In the near future I also intend to revisit some of my earlier, more scientifically oriented, blogs with the aim of bringing them closer to practice, opening them to a wider audience, while still not trivialising the underlying scientific challenges.

Slow Science; The road back to true science?

2009-02-28T09:03:00.000-08:00

I was planning to write a blog entry on "Science 2.0". Increasingly, scientists make use of blogs to communicate about their research, in addition to traditional forms of publishing. I think this is really a positive sign in the sense that it may indicate a move back to more open scientific debates. I intended to discuss how science may have to change its trades in the sense that over the past 40 to 50 years, the scientific debate has made way for a competitive trade of producing ever more papers and even more citations to one's work. Meanwhile, the focus on measuring scientific production instead of fostering scientific debate has produced several, documented, negative side-effects. Sure! Quality of academic research is an issue, but reducing it to paper-counting is likely not to be the answer. What is known as bean-counting in industry has been supplemented by paper-counting in academia.

That was my plan. But then, I wrote my two previous entries on From "think-unless" to "act-unless" and Time for a new renaissance? This triggered me to rethink. I still feel a shift to more open scientific debate away from paper-counting, but i think the damage done by the paper-counting has a deeper origin.

It might be different in other scientific fields, so I can only focus on the field I'm most familiar with: (computerised) information systems engineering and enterprise engineering. Within these fields, I do think that the strong focus on the numbers game, has resulted in a focus on act rather than think, or to be more precise publish-fast rather than observe-think-debate-experience-debate-think-debate-publish. The result of this is that there has been a shift in attitude. Conference visits are not about scientific debate anymore, but about the citation index of the proceedings and getting people to cite your work. Not necessarily bad things but if they replace the scientific debate, then it is worse than a bad thing.

In line with the previous two postings, I would like to argue that we need a shift towards slow science, taking more time for think-debate-experience-debate-reflect-debate-publish. In retrospect this has been one of my core drivers to move back from a full-time position in academia to a combination between academia and industry. For my type of research I really need a lot of debate with practitioners, experiments, et cetera. However, it tends to take a long time to really learn about the fundamental problems of enterprise and information systems engineering in practice. This does not always lead to publishable papers. Even more, actually wanting to publish at that stage is actually a sign of the publish-fast problem. It would be better to be able to have open debates about preliminary thoughts and insights, for example using a blog. The result is, however, that it will take a lot of "non productive" time, in terms of paper count, before actually reaching the point of being able to publish results.

Another negative consequence of the number game, or paper counting, is what one of my former colleagues (Hans Bossenbroek) used to refer to as "scientists walk backwards towards the future". Formulating innovative research ideas and research proposals is hampered because scientists are required to show a track record in the specific field. Of course in terms of publications. As a direct consequence, one can only move forward based on past results and not leap ahead to novel ideas and concepts.

To me these observations are one of the key drivers for moving to a situation where I can combine work in industry with work in academia.

Time for a new renaissance?

2009-02-27T12:17:00.000-08:00

Reflecting more on my previous post, i realised that balancing between "think unless" and "act unless" should really be thought of as an attitude issue, and not some technique. Just as well as Zen is not just a technique, but something deeper, an attitude, a spiritual way of being, balancing the think/act principles requires more than applying a technique.

The balance requires a continuous awareness of the tensions at play:

Have we done enough thinking?
Aren't we stalling to much, before really acting?

In the context of business and IT transformations, my playing ground, we really need more of this balance. Especially in terms of a change of attitude. Business management, program managers, enterprise architects, IT architects, project leaders and engineers, all should do some critical introspection to see if they strike the right balance between thinking and acting. Especially in the current crises. Should we panic? Should we blindly cut costs? Or should we carefully rationalise activities based on priorities, consider undesired side effects within the business and social ecology as a whole, and prepare for the future? It takes leadership and courage to think first and to then act decisively.

In my view, over the last decennia, we have been under the influence of too much of an "act-now; think-later" attitude. Even more, I think that ever since the second world-war, we (especially in Western Europe) have been pushed more and more into this direction. An approach which might be regarded as a direct consequence of the pioneer mentality that has been dominant in the United States of America. And indeed, much of the "act-now - think-later" has been spread along with the growth of the USA based way of doing business. Thus far, this has lead to a demise of the European "Rhineland" way of doing things, which has always been more geared towards a "think-first - than-act" attitude. The two stereotypes sketched in my previous post really are isomorphic to the stereotypical distinction between Europe and the USA:

The USA barges in without thinking.
Europe won't act because they are too busy thinking.

I know these are stereotypes, but there is some truth to it.

There is currently a growing interest in taking things more slowly; more carefully; more thoughtful. This is exemplified by sites such as SlowPlanet. My colleague Ron Tolido maintains a blog on this site focussing on SlowIT. Interestingly enough, or should I say, importantly enough, this slow movement dates from before the crises.

Looking at the current economic crises, and its causes, I really think we should all take the responsibility and take some SlowPlanet lessons. It is time for Slow Business and Slow IT, or like Ron Tolido put's it: The Art of Careful Technology. Well, we can all do with some more care into the way we deal with the crisis and the way we can move forward.

Maybe, just maybe, we are at the start of a new renaissance. A better balance between thinking and acting? A renaissance of European-style thinking and enlightenment?

From "think unless" to "act unless"

2009-02-26T11:02:00.000-08:00

There is this old issue of "analysis paralysis". In other words, spending lots of time on analysing a problem at hand, studying several potential solutions, all the while not solving the actual problem as it exists in the real world. This has resulted in several caricatures of analysts and designers losing themselves in "model space", while enjoying large quantities of coffee in their ivory towers.

Meanwhile, at the other extreme, we find the pushy project manager who only has sight for the project deadlines, as well as the eager, hyped on coca-cola, engineer who already has "the solution" and looks in total amazement at those analysts who still haven't found "the solution".

Then there are cases where one makes hasty decisions during analysis and design, bravely referring to "pragmatism", where this is really used as an excuse to not think. "Well, you know how it works in practice, we have to be pragmatic". More often than not tomorrow's legacy in the making!

Somewhere deep down, all of us really know we have to think before acting. We all know about the proverb of sharpening the ax before cutting the tree. At the same time, it is wise to make sure we do not end up with analysis paralysis.

In my opinion, when confronted with a "problem", we should start by gauging how much time is available before a solution should really, really, really, be implemented. Say n hours. Now divide n into two halves. During the first half, we should operate according to the principle of think unless, while during the second half we should adhere to act unless. In other words, during the first half any urge to start acting should be treated as suspicious and as a signal of trying to "avoid thinking in the name of false pragmatism". During the second half, any urge to continue thinking without acting should be banished, and branded as an attempt to shy away from actually getting work done.

Of course one should always be prepared to reduce n when we learn new facts about the problem, and jump more quickly to the act unless mode when needed.

During the think unless stage, several excuses may pop up triggering us to start acting prematurely. Use this as a trigger to once more establish if your estimate of n is correct. If so, once again examine your assumptions on what the problem really is. Is the designed solution really going to solve the right problem? How can you be sure? Doesn't it cause undesired side-effects? Do you have the abilities and resources available to realise the solution during the act stage? If you're absolutely certain that you're on the right track, then take a deep breath, and move to the next stage with confidence. Once in the act unless stage, make sure you don't fall back into thinking unnecessarily. Accept the fact that you haven't found the perfect solution. In the end, a solution is better than no solution.

If you're not really sure about n, one strategy might be to start by formulating a time-boxed hypothesis of the problem and its solution. Then expose these hypothesis to challenges/scenario's, and continually refine the hypothesis of the problem and its solution. Once you're halfway through to n, trust your hypothesis and stick to it! That is, unless you really hit a big snag. Then it is time to use the unless part of the act unless principle.

Getting stuck into analysis paralysis might at times be caused by analysts loosing themselves in "model space". However, another important causes is reluctance of decision makers (not just the analysts and designers, but also sponsors and owners) to make decisions when there is no analytical answer to be found. In other words, reluctance to take the lead. True leadership requires the courage to make gut feeling decisions. These cannot always be rationalised.

WiFi in hotels? Hot water not included!

2009-02-22T22:13:00.000-08:00

Just a short blog this weekend. Well. If you actually count carefully, you will see that I am lagging behind in my new year's resolution to post one entry per week. One of my colleagues (Ron Tolido) keeps telling me to write shorter blogs anyway.

We live in a day and age where access to the internet is almost ubiquitous. Fair enough. This only applies to the so-called Western world. When disgracefully limiting our view to the Western part of the world, internet access is everywhere. The invisible infostructure is neigh. In whichever city you are, places like Starbucks provide you with free internet access.

But wait. What happens if you travel around? I've noticed that when I'm traveling around, the cheaper hotels quite often provide free or really cheap WiFi access, while the more expensive hotels tend not to. At the top end hotels you end up paying 15 to 20 Euro a day to get WiFi access. In the age of the invisible infostructure, I think this is almost like having to pay for hot water. "Do you want hot water in your room sir? That'll be an extra charge of 15 Euro per night." Rediculous! How many travellers carry a WiFi enabled device? Its not as if they would be offering this service to only a few. Everyone takes a hot shower. Everyone needs WiFi.

Let's boycot hotels without free WiFi, or at least start asking if hot water is included in the price ...

Looking at it from another perspective, I am actually amazed that I haven't come across Google (or Microsoft for that matter) sponsored WiFi access points yet. Imagine sitting at an airport or a railway station, and getting internet access for free, but before you login you will have to go theough a login page of the sponsor. Sure. It still sounds a bit like "Today's hot water was sponsored by ...", but still, if there is a need to earn an extra Euro from the use of what should be as common as hot water ...

Even more, companies like Google could link the knowledge of which access point you're using to their AddSense system. The Google adds you see on web-pages only have a topical relevance in relation to the content of the web-page you're looking at. What if they could add location-based relevance? The add could say "If you feel like coffee, there is a nice espresso bar just round the corner".

Model assisted problem solving in multi-actor environments

2009-02-18T22:45:00.000-08:00

Building further on one of my previous blogs on model-based enterprise engineering I came to the conclusion that model-based enterprise engineering really is an application of what I would like to call "model assisted problem solving in multi-actor environments". This may sound as an over-the-top generalisation, but it think it also signifies the core competency of enterprise engineers and enterprise architects. And at a time of crises I think it is wise to better understand the core competency of our profession.

Note that the word "problem" should be interpreted in a broad sense. Moving from e.g. a formulated business strategy to a plan for its actual execution can be regarded as a "problem".

When moving from a "problem" to a "solution", one will go through the earlier discussed assess/aim/act processes:

During the assess process, models are used to capture knowledge about the problem, its context, and what should be done about it. This requires more than modelling skills alone. It also requires elicitation techniques, as well as strategies to get multiple people (multi-actor environments!) to agree on a shared understanding of the problem.
In the aim process, models are used to evaluate alternatives and make explicit what the chosen solution will be. Again, this requires more than modelling skils. Agreement on, and more importantly, lasting commitment for, the chosen solution in a multi-actor environment certainly is no trivial task. In terms of the models formal analysis can be made wrt different properties of a desired solution.
During the act process, the models serve as a base to guide the implementation/execution of the chosen solution and/or for compliance testing. Again, the multi-actor environment is likely to produce additional challenges.

During the act process we may end up in a "recursion" in the sense that it needs to the need to solve several smaller problems. For example, the creation of a highway connection between two cities first requires a high level analysis of the problem it would aim to solve, followed by a design of the actual highway in terms of the path it will follow, overpasses needed, junctions needed, etc. Once this has been established, the act process involves several smaller projects e.g. focusing on the creation of a specific bridge. The same aplies to enterprise transformations. It starts at the portfolio level dealing with the general directions. This leads to a number of programs executing different parts of the transformations needed. Each program will comprise of more manageable chunks of work in terms of projects.

Clearly, this cycle of problem solving using models does not only apply to the architecting or engineering of enterprises, or aspects thereof (such as its IT). In that sense I would like to argue that we (as architects) need to take a closer look at more general theories on problem solving. See for example a survey included in the WikiPedia.

When dealing with model assisted problem solving in multi-actor environments, we are typically confronted with situations of a high social complexity. In other words multiple actors with multiple, contradicting, stakes in the problem and its solution. What makes matters worse is the fact that the problems themselves tend to have a messy or wicked nature. Authors like Horst, Rittel and Conklin, a summary of which can be found on the WikiPedia, typically characterise wicked problems as:

There is no definitive formulation of a wicked problem.
Wicked problems have no stopping rule.
Solutions to wicked problems are not true-or-false, but better or worse.
There is no immediate and no ultimate test of a solution to a wicked problem.
Every solution to a wicked problem is a "one-shot operation"; because there is no opportunity to learn by trial-and-error, every attempt counts significantly.
Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
Every wicked problem is essentially unique.
Every wicked problem can be considered to be a symptom of another problem.
The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution.
The planner has no right to be wrong (planners are liable for the consequences of the actions they generate).

which are indeed rather challenging indeed.

In solving such problems, models can play very important roles:

Models may provide insight. Either directly or indirectly by deriving views from the models that answer/focus on specific questions/issues. This insight might be needed towards an informing purpose, a decision making purpose, analytical purpose, resolving of disputes between stakeholders, etc.
Models may provide guidance towards the execution of work. This could be design activities, the operational execution of work, etc.
Models can be used as a means to share knowledge about the problem and the selected (and not selected!) solutions.
Models can be used to explicitly represent the state of a problem solving process. In other words, the understanding of the problem/solution at some point in time.
Models can act as a formal a steering/regulation instrument.
They can act as a common frame of reference, i.e. an ontology.
They can be directly executable or at least formally interpretable (MDS and MDA!).

In further evolving the idea of model assisted problem solving in multi-actor environments, we can make a distinction between the different domains in which problems are solved (medical diagnosing, enterprise engineering, software engineering, ...) as well as the wickedness of the problem itself in terms of social complexity and cognitive complexity.

Having said this, it is probably interesting to see how the ADM (architecture development method) of TOGAF relates to general problem solving approaches.

Models that matter; Return on Modelling Effort

2009-02-02T09:55:00.000-08:00

In the context of enterprise architecture, IT architecture, (software) system development, et cetera, we use several models. Some models have a descriptive nature (e.g. UML, ArchiMate and DEMO models) and some have a prescriptive nature (e.g. sets of business rules and architecture principles).

All of these models are created for many different purposes. At the same time, the creation of these models takes time and effort. In other words, they cost money. This raises the question of how these investments can be put to good use? How to increase the return on investments put into models? In other words, how to achieve return on modelling effort (RoME)?

Since a year or two, my research group at the University of Nijmegen has been using the return on modelling effort question as one of the drivers in its research activities.

Below I'll venture out and explore some potential returns of modelling efforts. Knowing beforehand what the expected return of modelling effort for a given modelling endeavour would be, also provides insight into a stopping criterion for the actual modelling. All modelling effort should be focussed towards the achievement of the planned/expected returns. In the past we did some explorative work on these issues:

Taking a return on modelling effort perspective on modelling may sound as an obvious thing to do. Nevertheless, most modelling/architecture approaches do not require modellers to reflect on the business-case for their modelling activities. As a result, there tends to be no stopping criterion to decide when the model is finished. Even more, some early approaches to the quality of modelling presumed quality of models to be an objective property of the model in isolation independent of the reasons for which the model was created, thus completely ignoring the need for a cost/benefit analysis.

In the context of enterprise architecture, the return on modelling effort is also a driving principle in Capgemini's book on Enterprise Architecture - Creating value by informed governance as well as the book by Johnson and Ekstedt on Enterprise Architecture - Models and Analyses for Information Systems Decision Making.

As promised earlier on in this entry, I would discuss some potential returns of modelling efforts. Of course I cannot list benefits in detail, but hopefully some of these will inspire you:

Models may provide insight. Either directly or indirectly by deriving views from the models that answer specific questions. This insight might be needed towards an informing purpose, a decision making purpose, analytical purpose, etc.
Models may provide guidance towards the execution of work. This could be design activities, the operational execution of work, etc.
Models can act as a formal a steering/regulation instrument.
They can act as a common frame of reference, i.e. an ontology.
They can be directly executable or at least formally interpretable (MDS and MDA!).

I'm sure I haven't listed all potential benefits, so consider this as an invitation to provide more suggestions. I might gather them in a future blog entry.

Model-based enterprise engineering

2009-01-25T23:14:00.000-08:00

Recently, Springer initiated a new series on enterprise engineering. This series defines enterprise engineering as:

Enterprise Engineering is an emerging discipline for coping with the challenges (agility, adaptability, etc.) and the opportunities (new markets, new technologies, etc.) faced by contemporary enterprises, including commercial, nonprofit and governmental institutions. It is based on the paradigm that such enterprises are purposefully designed systems, and thus they can be redesigned in a systematic and controlled way. Such enterprise engineering projects typically involve architecture, design, and implementation aspects.

The increased complexity of enterprises as well as the ecologies in which they operate, the introduction of more regulations and compliance requirements, all require enterprises to be more explicit about their organisational design and performance.

I take the position that enterprises should turn to the use of models to make the design, as well as the performance, of organisations explicit. It also enables the conscious trade-off of different design alternatives in terms of analysis of models representing the different alternatives. I therefore would like to argue that enterprise engineering should be regarded as a model-intensive activity.

As such, I believe enterprise engineering can benefit a lot from the model-based competencies build up in the fields of information systems engineering and software engineering. It does, however, require these competencies to be extended beyond their traditional "IT focus". I do realise that both the fields of information systems engineering and software engineering have produced modelling techniques that cover more than just computing aspects. However, in terms of Morgan's Image of Organization they tend to take a machine-oriented perspective on organisations. A future challenge is to increase the richness of our modelling techniques to also include/enable other perspectives or organisations.

When looking at enterprise engineering, we could roughly define a (continuous & cyclic) value chain of modelling activities, covering:

Assess - Insight into the performance of the current sitation of the enterprise. Its performance and/or its base-line design/architecture.
Aim - Selection, evaluation and articulation of the desired target design/architecture of the enterprise.
Act - Usage of models to govern (manage & direct) the transformation of the enterprise in the direction of the selected target.

In each of the stages, several model challenges can be discerned:

Assess - Models of the existing situation need to be produced. Mixing elicitation of the current situation from domain experts, or by mining of observations of the operational situation. A shared understanding of (and consensus about) the models needed among the key stakeholders. The resulting models can be used to further analyse the desiredness of the current situation. This requires rich analysis techniques.
Aim - Identification of requirements/constraints of "ideal" alternative as well as the path towards the achievement of this ideal. Formulation of different alternatives in terms of models. Evaluation and analysis of these alternatives (and the paths towards their realisation) in terms of the identified requirements. A shared understanding of (and consensus about) the selected alternative should be attained.
Act - Monitor and direct the realisation of the desired target enterprise. Since the realisation, as executed by projects, involves models as well, from an analytical point of view this would boils down to forms of model verification.

Once more, the assess/aim/act phases should be regarded as highly cyclical.

The Restaurant at the End of the Internet

2009-01-24T03:31:00.001-08:00

I call my blog The Restaurant at the End of the Internet, which is a link to Douglas Adams' 'trilogy' on the Hitchhiker's Guide to the Galaxy. In my PhD, each chapter started with a quote from the Hitchhiker's Guide. Except from the last chapter, where I wrote the following:

Maybe, just maybe, the dolphins were right after all, and it would have been better for man to have stayed in the oceans, and not have bothered to migrate to the land.

It certainly would have been a lot better for most other species on this beautiful, yet fragile, planet. The collective sanity of the human species, is indeed reflected by the very name the humans have given to this planet. What other species would refer to a planet who's surface is mostly covered by water as 'earth'? Every other intelligent species in the universe would have called this planet 'water'.

The dolphins did.

Jokingly I quoted this text as coming from The Restaurant at the End of the Internet.
15 years after making up this quote, and looking at what we are still doing to our planet, I think we should listen more carefully to what the dolphins are saying.

Blogifying my publications list

2009-01-23T06:51:00.000-08:00

Yesterday I've started blogifying my publication list. In my role as an academic I have my publications listed on my home page. This doesn't allow people to respond/comment to any of the publications. So ... why not create a blog version of them. Publication details, abstract, and a link to the actual publication, and presto!

The growing (transferring will take a few weeks) list is available on http://erikproper-publications.blogspot.com

Cross blogging

2009-01-22T07:29:00.000-08:00

Last year I already blogged about cross blogging. What i'll do this year is possibly blog in other locations as well, but use this blog to gather my postings, and possibly event digests of comments.

Why? Well, to create an archive. If only for my own purposes.

New year's resolution

2009-01-22T07:19:00.001-08:00

A new year! Time for new year's resolutions!

Fair enough. The new year is already three weeks old, so maybe I'm a bit late with new year's resolutions. At the same time, we've just passed the third monday of the new year. It seems that the first monday of a new year is the most depressing day of the year. One of the reasons being that this is usually the week in which one realises that all these new year's resolutions have already been broken.

Therefore ... time for my new year's resolution ... I shall blog more. I shall blog more. I shall ....

But ... this was my resolution last year as well. So what's different this year? The basic excuse for not blogging was lack of time (or priority). But, it's probably also caused by the fact that I'm used to writing scientific papers rather than blogs. I need to develop a new discipline of writing shorter bursts, rather than "short papers". Therefore, I think this year I'll stand a chance of blogging more regularly. Maybe even once a week.

Fundamentally understanding IT? - Why Web 2.0 needs architects. Part II

2008-02-12T03:40:00.000-08:00

This is my second blog entry related to my claim that Web 2.0 needs architects. It's been a while since the first one because I've been working on a new book on enterprise architecture (as also mentioned in the previous entry). This blog entry is to some extend a raw dump of some thoughts, and hasn't really been polished. I just didn't want to wait much longer. Nevertheless, I hope that it, even in its current form, sparks some discussions.

In my opinion, Web 2.0 is yet another technology trend in the list from OO, via CBD, ORB's, to The Web, SoA, XML, Semantic Web, Web 2.0, .... Thinking about the promises of Web 2.0, and the role of (enterprise) architects in this made me go back to an old question: What if we can create a paradigmatic model of IT in terms of which we can explain current IT trends and predict future trends, or even derive directions for future technology developments? Rather than having to be bystanders while one new technology passes by after the other, we would be able to al least position and predict some of these technologies, and possibly take the lead in creating new technologies. Mind you, one does indeed need to remain aware of any paradigm breakers.

As a conceptual modeller (ER, ORM, DEMO, SBVR, ...) I’ve always been interested in creating/finding an abstract model of information technology that allows us to generically reason about the abilities of technology irrespective of trends/technologies that pass. Around 2001, we were toying with the concept of an ActorWeb (see http://www.cwi.nl/events/conferences/Components/Proper.pdf). This "we" consisted of some people from Ordina, Escador and CWI (Centrum voor Wiskunde en Informatica), while also having some interactions with Hans Goedvolk from Capgemini, who had coined the notion of Actor-based Information Systems. Regretfully, we have never been able to turn this into a proper research project, and since one of our other ideas was evolving into what is now known as the ArchiMate project, we put this idea of an ActorWeb on ice.

The basic idea of an ActorWeb is to view IT around us as a set of actors interacting amongst each other as well as with the social and physical world. To understand what this might mean at a more concrete level, I’ve spent some time thinking up the following example model. Mind you, it’s just intended as a suggestion to show how such a paradigm might allow us to position and analyse technologies.

Let’s think of IT systems as a digital world harbouring a society of digital actors supported by a digital ecology. The actors interact to each other, they may have a memory and cognitive/computing abilities, and some may even interact with actors in the physical world. The society of digital actors lives in a digital ecology created in terms of hardware and low-level software (operating systems). The digital ecology does not always have to be a connected whole. So interactions between digital actors living in different parts of the ecology might sometimes be hampered.

Each actor in our "digital society" has, analogous to human society, certain abilities and properties. Let’s presume all actors are able to communicate to other objects. Let’s furthermore presume that the least thing they can communicate is their (unique) name. More advanced abilities would be:

the ability to cling to an object in the physical world (think RFID!)
the ability to cling to an object in the digital world.
the ability to take measures in the physical world (location, temperature, etcetera)
the ability to measure the proximity in the digital ecology to other actors in the digital world (e.g. two digital actors running on the same network-node versus two running on different nodes). The proximity might refer to computational locations/nodes, but also to time.
the ability to measure the proximity in the physical world to other actors from the digital world (e.g. a digital actor in an RFID chip clung to a book passing by a sensor harbouring a digital actor being able to sense the physical proximity of digital actors living on RFID chips). This proximity might refer to physical location as well as time.
the ability to interact with actors in the physical world.
the ability to manipulate objects in the physical world (e.g. robots).
the ability to manipulate objects in the digital society (or even the ecology).
the ability to move around the digital ecology in such a way that the actor has a different physical location (i.e. moving from one server to another).
the ability to store large amounts of information.
the ability to reactively respond to stimuli.
the ability to pro-actively exhibit behaviour.
the ability to compute.
the ability to reason/infer.

In addition, we might divide the digital actors in different classes, which could be defined in terms of the above identified abilities:

Sensors: Actors which can take measures in the physical and/or digital world.
Manipulators: Actors which can manipulate objects in the physical and/or digital world.
Tools: Actors which can conduct well-defined basic computational work (typical applications, storage, etc)
Translators: Actors which act as translators to enable the communication between other digital actors.
Bridgers: Actors which can translate between actors in the physical world and actors in the digital world (a voice interface, a GUI, or a brain interface).
Brokers: Actors who known about the ability of other actors (in the digital and/or physical world) and are able to bring them together to collaborate.
Agents: Actors who are able to execute complex tasks involving reasoning and trade-offs. They are likely to do so on behalf of a human actor in the physical world.

Now look at some basic examples from IT through the perspective of this paradigm.

SoA: A service is an ability on offer by a specific actor. They may be advertised by a broker.
Word processor: Is a tool using a bridger (the GUI) to obtain input from a human actor telling it what to do in manipulating another digital actor: the document.
Navigation system: Is a tool which talks to a sensor telling it where we are, and using a bridger to obtain from the driver where they want to go, as well as telling the driver what to do.
Digital camera: Is a tool taking a picture on a command issued by way of a bridger (the release button) and consequently talking to a storage tool (materialized as a the memory card) to store the picture. At home I physically move the memory card housing the digital actor "storage tool" to my computer’s card reader and tell another tool (e.g. Adobe's Lightroom) to fetch it.
Screen scraping: The worst kind of interaction between digital actors, where the two actors need to resort to using two bridgers to interact.

Consider, as a more elaborate example, my address book. My address book really is a collection of digital actors (tools). It is not a single tool actor, but really a collective: some of them live on my notebook (Thunderbird’s address book and Outlook’s address book), one lives somewhere out there (Plaxo!), another one lives on my palm, and one living in my phone. They keep each other in-sync using translators. Now if we look at reality, we immediately see some potential improvements of this scenario, and the technologies used:

Regretfully in some cases I have to initiate the synchronisation manually. What I would love is for them to keep each other in-sync automatically. When my phone is able to contact the “big” digital ecology (the Internet), it should sync with the address book living at Plaxo automatically.
Why do I need two address books on my laptop? Can’t both tools (Thunderbird and outlook) talk to the same address-book-tool?
When I buy a new phone, I need to look for a translator myself to enable synchronisation between my new phone and my pre-existing collective.

As a human user I am willing to accept that I must be aware of the fact that I need a collective of tool actors to create my address book, since the physical dependence of the digital ecology might not always allow for an interaction between my phoning-tool and my address-book-tool. However, why do I need to be bothered by manual synchronisation, and even worse, translations during synchronisation. This makes the role of the translators important. Ideally, when I’ve bought a new phone, I would like to tell my address-book collective: listen guys, this is Nokius, he speaks Finish, now start talking to him. They would then invite the right translator to join their collective and then update Nokius, and keep it in sync.

So how do we create this world? First of all, it is already possible to use a paradigm like the one discussed here as a design paradigm for systems. In other words, when designing new systems we might be looking for the different types of actors (and most probably be adding new types to the paradigm). Furthermore, by tuning the behaviour of actors in the web, in particular the agents, to the needs of the people, we can achieve a more personalsed experience. And beyond that? What about a societal experience? Imagine the actors in the digital world and the physical world being so well integrated that we work together as a collective. Sounds funny? Imagine an agent from the digital world, who/which has been doing a number of useful things for you, asks you to do something in return because it is working on a task for someone else ...

The role of enterprise architects

2008-01-17T13:09:00.000-08:00

This week I will not yet continue my Web 2.0 series, but rather respond to a comment on my last post. My claim that Web 2.0 needs architects, led to a comment/question:

Especially the phrase 'of course' caught my attention. Why do you think enterprise-architects should already be involved this early on in the process? Is strategy in their domain too? I would be very interested in seeing a post why you feel enterprise architects add value to an organization, and what you feel should be part of their responsibilities. If you make me really happy, please address the role of enterprise architecture in relation to the effectiveness and efficiency of information security controls.

Which was a direct response to my statement: "This actually triggered me into realising that the Web 2.0 needs information architects. Of course, when an enterprise considers utilizing Web 2.0 technologies an enterprise architect should be involved in deciding-on/designing the best way of doing this."

In line with my earlier blog on three perspectives on architecture, we regard enterprise architecture to be: "a coherent whole of a design-oriented, a regulation-oriented and a pattern-oriented perspective on an enterprise, providing indicators and controls enabling the informed governance of the enterprise’s evolution and success". The we in this case refers to the consortium of Capgemini and Radboud University Nijmegen offering the Master of Enterprise Architecture program. We position architecture between strategy and transformation programs endeavouring to realise the strategy. This is based on the believe that present day organisations are confronted with socio-economical and technological challenges that require an abstract means of steering the transformation of enterprises, that offers more specificity than a strategy can offer. As such, enterprise architecture is a tool or means to support strategy formulation, planning and transformation execution. It enables informed decision-making, planning and governance of the transformation execution. As a means it can be used: within strategic business/IT planning; to align strategic objectives and IT; to define and guide large scale business IT/transformation; to structure organisation re-engineering; to enable design of organizational networks (shared service centres, BPO, etc.); to define and monitor IT programs.

Going back to the original question "Why do you think enterprise-architects should already be involved this early on in the process? Is strategy in their domain too?": Architects should indeed be involved early on in the process. They are not responsible for the formulation of the strategy, but they can certainly aid in creating attainable strategies that play into the opportunities provided by the enterprise’s abilities (based on the insights of the enterprise’s architecture).

An enterprise architect clearly also has a role to play towards information security. More specifically, an architecture should provide insight into all sorts of risks as well as their potential impact. Those risks pertaining to security issues, and which have a high likelihood of occurring, can then be used to initiate further measures. These measures could be security principles that become part of the principles-oriented perspective of the architecture, or they could be operational security rules that will find their place among the business rules used in the operational enterprise. In short, an enterprise architect certainly has a role to play here. It is also no coincidence that the earlier mentioned Master course on Enterprise Architecture also features a subject on security and enterprise architecture.

Currently, we (the Capgemini/RUN consortium) are writing a book on the value and use of enterprise architecture, as well as the responsibility of architects. We expect to finish this book this summer.

Why the Web 2.0 infrastructure needs architects - Part I.

2008-01-09T08:19:00.000-08:00

This blog entry is cross-blogged between the VNA website and my own blog site. I like to keep my blog entries, as well as my comments to other people’s blogs, accessible through my personal blog site. The result is that people will be entering comments on different locations. Even more, since Plaxo also includes these blogs in my pulse stream, people can even respond to my blogs in plaxo, and I have noticed that these comments do not automatically show up on the original blog sites. Of course one might argue that "cross blogging" should not be done, but at the same time I think it is a defendable stance that I should be able to publish my blog (and their comments) through multiple channels.

This actually triggered me into realising that the Web 2.0 needs information architects. Of course, when an enterprise considers utilizing Web 2.0 technologies an enterprise architect should be involved in deciding-on/designing the best way of doing this. However, I also think the technology itself needs more architecting, or at least some good old conceptual thinking.

I will try to argue in favour of my position by discussing (at least) three consecutive blog entries in which I will briefly look at specific cases. In discussing these cases I hope to illustrate the importance of more conceptual reflection of the design of these technologies. I do not intend to do a redesign. I only hope to raise some interesting design questions. In the first case, this entry, I will look at blog entries and discussion threads. In the second entry I hope to raise some design questions about notifications mechanisms dealing with new web content. e-mails, new discussion items in a thread, etc. In a third entry I aim to look at making a distinction between the applications around us and the communication channels we use to interface with them (be it via Web, e-mail, mobile phones, IM’s, voice, or whatever).

Back to blogs and cross posting. In the remainder of this blog entry I hope to take a journey along a number of design questions pertaining to blogs, news servers, discussion threads, public discussions and private discussions, and e-mail. For people new to blogging, news servers, e-mail, etcetera, the channels through which one can publish/discuss one’s ideas and thoughts are overwhelming. Why does it have to be so complicated? When posting a blog entry, one merely wants to start a discussion/dialogue. The same applies to a posting on a news server, or an (open) e-mail to a group of recipients.

Let’s start with blogs. What is a blog really? At first glance, a blog could be thought of as comprising of an initial posting followed by a sequence of comments, while this construct is usually displayed on some website. But, why make the connection between the content of the blog and its presentation explicit? Any database designer will argue that a distinction should be made between content and different ways/forms/locations of presenting this content! Imagine having a distinction between a blog-content server and blog-presenting applications. This would enable people to submit a blog to a blog-content server, and have it being displayed on multiple (relevant) blog sites. In other words, I would be able to write one blog entry (which you might add comments to), which is stored in one (logical) location, while being displayed (including comments gathered from all directions) at any blog site I choose to.

Once we have taken this step, we can actually think off blogs as being stored on a server with a well-defined interface such as a news-server (NNTP) or a mail-server (IMAP), while being displayed (as an interactive entity to which new comments can be added) by means of multiple applications (blog sites, Plaxo, etc). One might even go as far as to offer NNTP and/or IMAP interfaces to the blogs. Given the fact that we can subscribe to people’s blogs using RSS feeds from our mail clients, why not be able to write (and read) comments to these blog entries using our mail clients?

But, if we are to regard blog entries and their comments as discussion threads we observe on news servers and indeed in our inboxes (see GMail’s discussion threads and/or the thread option in your favourite mail clients), why not unify all of these? Indeed! Why should we have to make a distinction between Web 2.0’s world of blogging and the old world of news threads? Why not unify this into the concept of a “public thread” served on servers and accessible by way of a myriad of applications? With a public thread I refer to a discussion thread that can be read and contributed to by basically anyone (maybe moderated).

In doing so we actually have to slightly revise our initial idea of a blog comprising of an initial entry followed by a sequence of comments. What one can typically see happening on news servers is that discussion threads branch off. In other words, a comment on an earlier posting may lead to comments on the comments rather than on the original positing. And indeed. Why would I not be able to write a comment to someone’s blog entry and regard this as a starting point of a new blog entry with its comments?

How about discussion threads on our e-mail folders? They are indeed discussion threads but they are not public. They live in our e-mail folders. Even more, they live in multiple e-mail folders in a loosely-synchronised way. Each of the participants of an e-mail discussion will be able to find a (partial) thread in their inbox, based on the level at which the participants have shared the discussion among the group of discussants involved. This makes e-mail threads similar, yet different, from public discussion threads. However, from a user-interface point of view (i.e. your e-mail client) there does not have to be much difference, it only needs to offer a “discussion thread interface”.

In the above discussion my aim was not to claim a specific re-design of blogs, e-mail, news servers, etcetera. However, I do hope to have illustrated that a lot of the technologies we currently use for news posting, blogging and e-mailing, which might benefit from some fundamental conceptual (re)thinking. In other words, we need architects to redesign Web 2.0.

Three perspectives on enterprise architecture

2007-12-25T08:13:00.000-08:00

This is a cross-posting (a cross-blogging?) from my blog at
Via Nova Architectura. The reason for cross posting this blog entry is that I want to keep at leas a copy of all my blog entries at a central location.

When looking at the different types of interpretations of what enterprise architecture is, I believe there are three main perspectives on what architecture is about:

A regulation-oriented perspective in which architecture is regarded as a way to govern the design/evolution/transformation of an enterprise by means of regulations. In other words, in this perspective architecture is regarded as a prescriptive notion limiting the design freedom with regards to the design and evolution of a system.
A design-oriented perspective in which the essential properties of a system are being designed. This perspective treats architectures as actual specifications of high level system designs focussing on `architecturally relevant' design decisions and tradeoffs.
A patterns-oriented perspective which focuses on the use of design patterns. This perspective forms a bridge between the regulative and the design perspectives. To meet the regulations set out in the regulative perspective, during design activities, suitable patterns can be applied.

When looking at publications, ranging from Alexander, Gamma, IEEE, ArchiMate, to Dietz and Hoogervorst, one can see these perspectives in different shapes and form.

In my opinion, talking about architecture only makes sense when acknowledging the complementary role of each of these perspectives rather than limiting the definition of architecture to merely one of these perspectives.

It's not your definition of architecture that matters, but what you do with it.

Why google scholar should maintain my publication list!

2007-12-25T08:12:00.000-08:00

Google scholar is a search engine for scientific publications. I wonder if it would make sense for google scholar to provide academics functionality which allows them to easily maintain their publication lists. Consider, just as an example, my list. I try and keep the publication details up-to-date, where possible and allowed I'll also add PDF files of (and/or links to) the actual paper.

As some of you may know, publications, and in particular citations of one's publications, have become the currency of the scientific community (whether that is good or bad is another discussion ... another blog entry to follow). This means that authors have a strong interest in keeping their publication record available and ensuring the publication data (meta-data) is correct and complete. Usually using some mechanism such as BiBTeX. See here for an example.

So why would google scholar want maintain this data for me? Well, I'm not proposing they do all the work for me, but, if you look at google scholar than they already have a lot of publication data concerning the publications of academics. At the same time, however, several faults are present in their data. It is in my interest, the interest of searchers, and therefore also in google's interest that this data is correct. So, if google were to provide functionality that would allow me to easily bring together all my publications that can be found in google scholar (also taking into consideration the many variations of my name: H.A. Proper, H.A. (Erik) Proper, H. Proper, Erik Proper and E. Proper), and link them up with the correct publication information I already maintain on my own publication page, then I would be willing to invest the time of getting this list correct. This would be a win-win-win (searchers, google and me).

My first blog

2007-12-23T23:50:00.000-08:00

Well, I have decided to start blogging. In most cases (iPod, Apple-TV, Mac Mini as VCR in the living room, etc), I am an early adopter. In the case of blogging I've been rather slack. I hope to remedy this now.

Rather than using this blog purely to publish my opinion / thoughts / ideas, I intend to use this blog as a notebook for ideas as well (and gather comments in the process). This notebook is not to be confused with the notebook I have on Google Notebooks with a list of resources on enterprise engineering and architecting.