Jorn Bettin

Jorn Bettin

Read latest work...

Connect with Jorn

Have a specific question for Jorn Bettin?

Email

Conclusion: Today business knowhow is mainly stored in two places: in human brains and in software systems. Both forms of storage share the problem that raw knowhow is not easily transferable from one context to another. Valuable knowledge is repeatedly lost through staff turnover and through technology replacements. Minimising knowledge loss requires determination and an understanding of the mechanisms that lead to unnecessarily strong coupling between business knowhow and implementation technology.


Read more


Conclusion: When designing a service-oriented architecture it is essential to provide a mechanism for connecting services from different sources. Enterprise Service Bus (ESB) technologies add value when the systems involved don’t make use of shared data formats and communication protocols.

The market now includes a number of mature open source ESB technologies. Selecting the most appropriate option involves looking beyond the technologies and understanding the factors that influence the quality of a service oriented architecture.


Read more


Conclusion: Given the hype around the interactive aspects of Web 2.0 and the continuing popularity of Business Process X – with X being any element of the set {Management, Modelling, Analysis, Re-engineering, Integration} – the role of artefacts in enterprise collaboration and in value chains is easily neglected. If an organisation looks beyond the hype and invests in a comprehensive and accurate model of artefact production and consumption, the result is an understanding of business processes and value chains that is much more useful than the average business process model.


Read more


Conclusion: User interface design, implementation, and validation can easily turn out to be the most expensive part of application development, sometimes consuming over 50% of the overall project budget. This does not have to be the case. If user interface and usability requirements are specified at the appropriate level of abstraction, the required design and implementation effort can be reduced by an order of magnitude, whilst consistency and usability of the resulting application is greatly improved.


Read more


Conclusion: Historically grown organisational structures and simplistic job descriptions sometimes stand in the way of creating a high-performance team. Taking personality attributes into account when assigning roles and responsibilities can have a measurable influence on overall costs, delivery time, functional fit of IT solutions, as well as on skill development in the team.


Read more


Conclusion:Organisations are drowning in complexity and information overload. At the same time, saving costs is at the top of the agenda. The only realistic path forward lies in tackling complexity head-on by deploying analytical techniques that help identify spurious complexity and confirm intrinsic complexity. Subsequently spurious complexity can be removed by surgical intervention, one step at a time.


Read more


Recently Wired magazine featured an interview with the CEO of Facebook where Mark Zuckerberg claims that Facebook does not regard other online networking platforms as competition, but that Google is the real competitor.


Read more


Conclusion:Software as a service seems suspiciously familiar, bringing up old memories of time share mainframe computing systems in a different era, and more recent memories of application service provider based software offerings. Repackaging of old concepts in new terminology is a technique commonly used by software vendors. However, don’t dismiss software as a service due to a lack of technical innovation. The current attraction of SaaS is a result of changes in the economics of IT infrastructure.


Read more


Conclusion: Proprietary web services are raising concerns about strong lock-in. Those raising the alarm bells paint a simplistic picture based on the assumption that services such as Facebook are representative of the web service landscape. Upon closer examination it appears that the doomsday prophets have a vested interest in prolonging the use of localised IT infrastructure. In reality the concept of web services opens new possibilities to unbundle and mitigate lock-in, allowing internal IT to focus on the core business and to outsource the operation of non-core functionality.


Read more


Conclusion: Building valuable software solutions increasingly means building solutions that run on the web, and that are not dependent on any particular operating system. Pervasive web connectivity leads to a new paradigm for building software architectures that is based around the availability of high quality web services and around the conscious use of Open Source software in selected areas to reduce vendor lock-in.


Read more


Conclusion: Four years of Service Oriented Architecture hype and a middleware product diet rich in enterprise service busses are starting to take their toll. The drive towards service based application integration often goes hand in hand with unrealistic expectations and simplistic implementations. Instead of a reduction in complexity, the net effect is a shift of complexity from one implementation technology into another. The recipe to shedding spurious complexity involves reducing the (fat) content on enterprise service busses.


Read more


Conclusion: One of the weakest process elements in the software development lifecycle of most organisations is the discipline of requirements engineering. Over-investing in requirements specification amounts to speculation on behalf of the customer, and under-investing in requirements specification leads to speculation by the software development team. The optimal balance involves selecting an appropriate set of artefact types, and minimising the effort for maintaining these artefacts.


Read more


Conclusion: One commonly used approach for model management in Unified Modeling Language (UML) tools centres on using package-based modularisation and versioning of models – but this leads to a complex and unlimited web of inter-module dependencies. Another approach consists in the use of a scalable multi-user repository, and versioning at the level of individual atomic model elements. The latter technique, although largely eliminating practical contention and consistency issues between users, still does not encourage good modularisation, and gives no indication as to the state of completeness of a model. Fortunately, there are a set of best practices that can be applied to ensure modularity is treated as a first-class concern, such that model versioning is adequately addressed with standard version control software and minimal additional tooling.


Read more


Conclusion: It is now increasingly recognised that small (domain specific) modelling languages hold the key for improving productivity and quality in software design, development, configuration, interoperability, and operation. Little custom-built languages can be introduced and exploited without necessitating any changes in architectural frameworks or run-time technologies – a characteristic that painfully lacking in the vast majority of software products and tools. One of the first steps to get started with domain specific modelling is the selection of an appropriate DIY tool kit to build software power tools based on little languages. Currently there are three mature tool kits in the market that are worthwhile considering and the number of contenders is increasing.


Read more