Security and Software-Quality are tightly related. Many security problems really are general software quality problems. The talk shows trends, root-causes and concepts for authority reduction. Usability is also touched. see BWCon Talk on Security and Quality at eXept AG
A talk at SPIQ in Freiburg on new dimensions in security
Dimensions of Security( powerpoint slides ).I've done a little talk on security for SPIQ. I tried to give an overview of some current problems and ways to tackle the awareness problem (e.g. by using threat models). I was going from technical things over to the social dangers without and with security. As usually, reality makes our fears come true faster than one would expect. The next morning I read about the european initiative by France, Sweden and others to collect ALL data from internet and phone traffic WITHOUT PROBABLE CAUSE. And of course terrorism is one of the reasons for that. And equally normal is that no explanation is given about the positive and negative uses of all those data. See Bürgerrechtsgruppen warnen vor europaweiter Pauschalschnüffelei
A talk on webservices security pdf version
Radio-Interview at SWR Stuttgart. Materials: Trends in the internet of the world
Starting with reliability problems of large scale portals, this workshop deals with performance, physical and logical architecture, information and distribution models, Java peculiarities and personalization. Can take anywhere between 4 hours minimum and 2-3 full days if going into details of physical architecture (security, loadbalancing) too.
This is a talk I held at Gymnasium Staufen during a students-meet-practicioners event. The idea is to show them how I do software development and what the issues are. It is almost impossible to cover such a large area without overwhelming the students. So if you have a better idea, let me know.
This talk sets the stage for a class on middleware for distributed systems. It covers RPC, Object based middleware, Messaging Systems and peer-to-peer technology. 30+ slides.
Anybody ever involved in real software development has learned that the usual software development methodologies seem to never comply with ones own experience. Nowadays - with the emergence of what I call "social" software development methodologies like XP and Scrum - this is not really news for us. But just about a year ago it looked like RUP would be the cure for all. This lecture makes a statement against high-ceremony software development processes and especially against the common belief among managers that you can "buy a success process" as the small book on RUP seems to suggest. Interestingly, in Objectspectrum 7/2001 Philipp Kruchten discusses so-called "misunderstandings" of RUP that turns RUP into a waterfall like process. He may be right but IMHO he also tries to schmuse into the now so popular XP, agile, scrum etc. movements (link to the fowler paper). But at least from what I read about RUP there is nothing in there that covers the fact that software construction is a deeply social process between highly skilled individuals. 30+ slides in German!.
Data warehouse technology and artificial intelligence in the context of web-mining proved to be very useful for large scale enterprise portals. Unfortunately it became clear that the people involved in building enterprise portals are usually not the same people involved in analyzing the results from a business perspective. The portal is at the same time a means to "sell" things as well as the tool to measure client behavior. This means that a certain GUI items role is overloaded. The talk focuses on text-mining methods since they seem to be the hardest ones and at the same time the most important ones e.g. in case of collaborative portal features (forum, e-mail). And of course, the overall importance of meta-information in a portal becomes clear once again.
Over the years, starting in 95, I have used SGML and XML technologies mostly for software development purposes e.g. like building domain languages, keeping configuration information, support lifecycle management through automated updates. While working for a large Swiss bank I've also used XML for meta-data management to run the development environment for a large-scale CORBA/EJB project. XML proved invaluable as the communication glue necessary to tap into legacy systems and aggregate the results. The term "XML bus" was used for this. Finally, while working on the concepts of a financial research information warehouse XML as an editing tool became more important because it meant shifting to a structured publising process - getting away from Word's Garbage-in-Garbage-out principle.
On of the funniest moments in my carreer was without doubt a CHOOSE event on XML - held in January 98 in Basel. We had a full house and I had invited Adam Rifkin and Rohit Kare (Rohit URL) - two people living the web live much earlier than most others. I still believe Rohits "evolution of document" to be a fascinating piece of literature. My talk concentrated on showing how XML works from a programmers perspective and how it could be used as the "DNA of a large system". Also transformation issues where a hot topic at that time after the merger of Swissbank Corporation and SBG to UBS. But it took a long time for IT management in the Bank to even start realizing the benefits of XML.
Those were kind of my fighting years for SGML and XML (e.g. fighting for deployment descriptors to be in XML format in IBM Component Broker - a EJB system) or for a meta-data repository for the bank.
This talks about requirements of a large scale distributed development environment and how an XML information bus could tie all the different meta-data of tools and runtime environemnts together. The goal is to have much more impact control and traceability as we have now. Ironically, while our object systems turn more and more distributed, the tooling behind stays local and file based.
Talks about the difficulties in introducing new technology into companies. The fight between the old guys and the new kids on the block. About architecture and social interaction. How we always seem to re-inforce technical separations (e.g. layers) with social structures (groups, teams, departments).