Coherent modelling landscapes

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:

1. 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.
   
   
2. 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:

1. value exchanges between the enterprise and other actors in a value web (e3Value),
   
2. the transactions between these actors operationalising these value exchanges and the essential processed needed to realise them (DEMO),
   
3. the implementation of these essentual transactions and processes in terms of tangible actors, applications and IT, in terms of an enterprise architecture (ArchiMate),
4. 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

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:

1. 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.
   
2. Models may provide guidance towards the execution of work. This could be design activities, the operational execution of work, etc.
   
3. Models can act as a formal a steering/regulation instrument.
   
4. They can act as a common frame of reference, i.e. an ontology.
   
5. 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:

1. models are not kept up-to-date without making conscious decision to disinvest in the actuality of the model,
2. 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:

1. 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.
   
   
2. 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.
   
   
3. 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

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:

1. My Macbook Air.
2. My iMac desktop.
3. An iPod touch (plus Nike+ sensor).
4. A dual sim mobile phone.
5. My home phone.
6. Some company supplied black Visa box I need to sync my cloud agenda to the company's agenda.
7. Apple TV.
8. iPod music/audio-book system in my car.
9. A Tom Tom in my car.
   
10. 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:

1. 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". 
   
2. 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

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!

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

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:

1. William of Baskerville, in The Name of the Rose, because of his combination of academic pursuit and practical application in solving problems.
   
2. 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.
   
3. 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.
   
4. 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?

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.