Friday, December 21, 2007

Software Architecture and Security

This is a about a very close relationship. A stable, consistent, well-defined and documented architecture is a crucial precondition to achieve a certain level of security. This is especially true in a world of web-technologies, peer-to-peer communication, ubiquitous computing - just to name a couple of trends and paradigms. But there does still a misconception exist on how to achieve this state of security. Typical approaches are the following measures listed without meaning and priority: network separation, appliances like firewalls and mal-ware detection, access control, monitoring, logging, encryption, and secure coding efforts to avoid buffer overflows and other nasty errors. I do totally agree on this list. It’s all a must in the world of TCP/IP based protocols, today’s operating systems and other of-the-shelf software products. But this is not enough. It is not possible to defend a software system where basic functionalities are not strictly separated in main components and without well defined interfaces. These components should be deployable on different nodes easily without greater adjustments. The identity of all actors (people and software!) in the system in order to achieve correct authentication and authorization must be guaranteed, especially in distributed scenarios. This enumeration is not complete but it illustrates the need of a basic foundation called architecture. Not easy to accomplish for complex systems but there is no other solution available. A simple example can help to illuminate this need. Threat Analysis and Threat Modeling are a probate approaches to find weaknesses in a system. Unfortunately, this is not feasible without having a documented architecture available. Any offer to do the documentation of the architecture afterwards is an unmistakable sign that there is something wrong. Security requirements must be addressed very early in the development process in order to be considered in architecture and design. If this is done, achieving the required level of security might be possible. To get back to the relationship thing, architecture and security have the same enemy: complexity (We all know this from Bruce Schneier). But well-structured architecture can help to tame this beast, by avoiding indirections, tons of wrappers and all the other things that make software inscrutable; well structured-architecture which adheres to one of the most important goals in software architecture: SIMPLICITY.

Tuesday, December 18, 2007

Software Architect: open minded and eloquent

There are a lot of job descriptions available for software architects. HR people have done a great job to list all the skills a candidate should fulfill. I expect, beside a solid and comprehensive technical background in computer science, distinct communication skills and the willingness to share his or her work and ideas. An architect should be prepared to explain the basic ideas, concepts and, of course, the architecture that is intended to be used in a project. A well documented architecture and a concise set of slides based on that are perfect tools to do this kind of job. In addition, I also expect the ability to give guidance to the team in order to provide a solid framework for development and to give them sureness that the concept will last. Guidance is especially important when times are rough and the schedule is tough. Okay, this might be enough when talking about my job description for an ideal architect, except the visionary thing …

Monday, December 17, 2007

How is SOA doing?

So how is SOA doing? There are so many products in store with the SOA sticker on the box. Great! This reminds me of the good old times when everybody claimed to have his or her software implemented strictly object-oriented. I don’t wanna be a bean counter. But I do have a couple of main characteristics that must be met to call the product “service-oriented”. First of all, essential functionalities, components and modules should be represented as services. These services must be able to talk to each other, shall be distributable and can be coupled dynamically in order to reflect business processes. This approach is especially useful for stakeholders like customers, marketing people and other sources of requirements. But I also expect more benefit from SOA for another group of stakeholders: developers and architects. A service-oriented architecture should address and support general problem domains like concurrency, persistence and a distributed approach. What I expect is that such basic functionalities should be encapsulated as services to make development faster and easier and to avoid that the same mistakes occur again and again. Sure, under the surface still exist objects, but they are covered by a service layer in order to get problems solved in a more consisted manner. If this is achieved on a broad base, developers will accept SOA as serious approach in software development.

Saturday, December 15, 2007

Teach your Architecture!

A well documented System – and Software Architecture is a great tool to teach your team and other stakeholders. Developers need to know where their place in the system is, to whom they are talking and by what kind of messaging and communicating. This avoids painful integration in the end and makes the development much faster. It’s also beneficial to introduce your project to new members and entities working off- or near shore, wherever, by avoiding this typical learning-on-the-job behavior which slows down the efficiency of a group. Change Management is another aspect. The impact of changes to the system can be examined much faster and in more detail when all parties have an better overview provided by a documented architecture.

Friday, December 14, 2007

Why doing Software Architecture?

… Well, it sounds simple but it is definitely not. One reason is that software architecture is still new in many project as software engineering is in general (in comparison to other engineering disciplines). Sad but true. Software architecture pays off late in a project and it is not that visible as running code or prototypes. Hence, the temptation exist to leave this out or to reduce it to a non acceptable minimum. It is pretty much the same handling as projects treat requirement management very often. If this is just halfway done you must pay in the end. Sure, it is a lot of work and it slows down a quick start and first results , but it is necessary. A software that does not meet elementary (non-functional) requirements like extensibility, robustness or scalability is more or less a quick-hack that does not satisfies the majority of the stakeholders in the projects. As a result, re-design and main changes will increase the overall costs extremely. We all know this. Okay, I will write more about the pro’s of decent software architecture in the next posting. Stay tuned.

Tuesday, December 11, 2007

Software Architecture as Critical Success Criterion

Basically, architecture is a must and a success criterion for software and system development, especially when we are talking about complex and distributed systems. We may argue about details, different types of definitions, description and realization. But if we question software architecture in general, we are not doing serious business. Architecture must be a fixed part of building systems, because software development is about computer SCIENCE and should be based on ENGINEERING principles. Nobody would argue about having architecture in the process of building houses, bridges, etc. We must attain the same level of maturity in software and system development, especially when we take in account that writing software is still a heuristic process. I concede it is still a rough and bumpy road.
My definition is pretty simple: Software Architecture is the main interface between requirement management and development. Software Architecture defines the basic components (or services), their main interfaces, their interaction, communication and distribution within the system. It reflects non-functional requirements like performance, robustness and stability (just to name three) in particular. In addition, software architecture is essential to tame complexity, the worst enemy of stable, secure and lasting systems. And, a decent description of the architecture is the best tool to explain a system to all stakeholders – customers, developers, testers, marketing folks and managers. This might sound simple but it is definitely not. Let’s discuss the reasons in the next posting.

Monday, December 10, 2007

Dresden's Art Gallery Online

This is great news. Dresdens Old Masters Picture Gallery has opened a virtual tour this summer. There is an extraordinary article on this event available at wired.com. If you guys can't make it to Dresden, just check this article and the link to the tour on the net.

Friday, November 23, 2007

NYC in November

Hey, we took the chance and visit New York a couple of days ago. And had a great time. Not just the New York Marathon was a great experience. We also went to Staten Island and Coney Island. More pics on a separate website soon.

Monday, November 19, 2007

Off-line Web Applications

Many approaches for so-called “Off-line Web Applications” employ a bunch of vulnerable technologies running on the client. Sure, content must be cached and presented (in case of disconnection) and this needs two components: a database and a web server. In a scenario where a web server is running on each client in a network of Off-line Web Application, it needs strict rules in terms of configuration measurements. Honestly, who cares about this? Not even browsers are configured in a way to reach a decent state of security on the majority of desktop machines. This is another example how vulnerable many Web 2.0 approaches are, beside AJAX and the underlying excessive scripting model. Just check on the Black-Hat Sessions (and presentations) to read more about the risks and known weaknesses. It’s frightening …
Actually, I should add the keyword – Security – to the description of this blog. It turns out that this topic occupies more and more time of my daily work and research effort.

Tuesday, October 02, 2007

Concurrency and Functional Programming Languages

Following the thread on new trends and concurrency – I think we will see functional programming languages as one approach to tackle concurrency. It is worth to think about this option. Haskell is an elegant programming language; it’s functional and not sequential. Complex problem definitions can be described (by using a functional language) in a way that parallelization (a concurrent solution of the problem) is feasible. Program code is written more abstract, on a mathematical / abstract basis. It is not machine or processor specific. Using an imperative language, parallelization is not a piece of cake; especially when we are talking about lock-free programming. The learning curve is steep and the outcome error-prone. The current status of programming languages, tools and RAD is definitely not ready to support mainstream development in order to support concurrency in a world of dual-, quad-, or … core processors.

Sunday, August 26, 2007

Atlantic Canada


We had a wonderful vacation time in Nova Scotia in July - great people, pure nature and delicious seafood.

Sunday, August 19, 2007

More Hot Technology Trends

I would like to rework (extend) my list of hot technology trends a little bit after having some interesting conversation. I definitely need to address:
  • Concurrency in a multi-core computing environment. This is basically an area where relief is needed. Existing solutions, either implicit or explicit, are not sufficient from my point of view. Not sufficient because of the complexity and the resulting learning curve for developers. In today’s world of mainstream development, many underlying details pertaining to the processor architecture are hidden by abstraction layers and programming models. Handling lock-free programming is not a piece of cake. I would expect that chip maker and RAD/Compiler manufacturer come up with a smart approach to handle this. And I’m not talking about functional languages …No question that this is needed. A constant increase in computing power based on higher “GHz’s” is limited by physical barriers. More cache is no way out. Server applications will handle this by load balancing. But desktop applications are different. Graphical centered applications (picture, video) and other complex computing stuff will need a robust concurrency concept/framework on all these dual-core, quad-core boards soon.
  • Sure, virtualization. Virtualization is basically everywhere, on the boards, within operating systems and as add-on products. The solutions are different in their concepts and the market is fragmented and sometimes confusing. But virtualization is a cool technology with a lot of promising use cases.
  • RFID-Tags are sneaking into many areas - industry, retail, and simply into out privacy (à ID’s, passports). A critical success factor will be the security aspect of such solutions. People care about the privacy of their information which includes positioning and profiling.
  • Widgets, Offline-Web-Apps, Local Web-Server (all this related to the Web-OS) – I will write about this in more detail soon.

Wednesday, August 15, 2007

Hi-Tech Search for Jim Gray

Hi-tech pioneer and veteran Jim Gray (some keywords: databases and transactions, linked to many icons from Google, Amazon, Microsoft, and others) is lost at sea. He left San Francisco Bay Area heading out for Farallon Island on Sunday, January 28, 2007. He and his boat, the fiberglass cruiser “Tenacious” vanished in the open ocean. A high-tech search started when it turned out that traditional search and rescue by the coast guard had been unsuccessfully. High-tech giants (mentioned above) worked together and created a quick, impressive combination of different technologies in order to find Jim. Unfortunately, this great thinker and engineer was nowhere to be found. Not even the tiniest remnant or debris of his boat could be detected. It sounds like a mystery and is a real tragedy for his family and friends. An excellent but also sad story was published in the wired magazine; August 2007 issue. We all hope that Jim will return. The efforts to find him, driven by Werner Vogels and other high-tech executives, is an impressive example how a great person can link very different people, interests, positions and companies in order to find a solution. Unfortunately, his accident was the trigger to make this happen.

Wednesday, July 25, 2007

... new and hot technology trends

Here comes my list of new and hot technology trends for the near future. I did not rank them but I will comment (and you could too) on them in more detail soon.

- Location Based Services

- The Web-OS

- The Semantic Web

- Information Categorizing and Mapping

- The Deep Web

- Medical Gadgets: cool tools which help you to survive in each and every situation

- Intelligent home networks: which connect all devices that should be communicate to each other

- Mobile Devices and GPS

- Better Anti-Malware Systems (if not, we are in trouble)

- Software as Services (most likely over the Internet, i don't like it but it is related to SOA)

- Sure, Social Networks, Communities, and Blogs on the Web

Thursday, June 14, 2007

My view on THE Web-OS

Many people are talking about a Web-OS. Just do a quick search via Google (one of the key player in this WebOS area). The results will be very different: some kind of decent information and ideas, some kind of rumors, all this stuff… I do believe in the idea of a Web Operating System which will be one of the top technology trends for 2008 or later. But I really miss a cool approach to bridge an existing gap. This is not about putting a web server on each client. This is about the technologies running in the browser which is still the one-and-only client for web applications. HTML is a markup language for documents, period. JavaScript is a scripting language, easy. Any combinations of both technologies might lead to more functionality and even to new trends like Web 2.0. But this comes with high complexity, security issues and huge problems to maintain code (and I’m not talking about debugging). My point is, HTML, JavaScript and AJAX are not the robust and durable building blocks to create a new operating system. This kind of homework must be done before establishing a new operating system; even it is “just” web. Disappointed?
___

Die Frauenkirche in Dresden


Tuesday, June 12, 2007

Convergence of SOA and Software as a Service

People might argue that SOA is just another hype in software development. That is definitely true for many applications with the SOA Sticker on the box. There is also some kind of misconception of the underlying implementation techniques. For many “experts” is the web service technology the one and only choice (I can’t agree on this!). But the concept of SOA is especially helpful in the phase of mapping use cases (and work flows) to implemented functionalities in scenarios where the interaction (between the functionalities) is changing constantly. This flexibility is one reason to make SOA happen (but, please, not for all types of software applications). In addition, I do see a great opportunity to match the business scenario of – Software as a service – with the idea of a Service Oriented Architecture. I’m pretty sure that such companies got this already on the agenda. Me too.

Sunday, June 10, 2007

IT Security in the Software Engineering Process

We don’t need to discuss about the significance of security in today’s world. Globalization and worldwide networking come with a lot of opportunities and might lead to more prosperity. But risks and issues must be addressed. We do see many threat vectors increasing. Many attacks are more sophisticated, very focused on a specific target and driven by high criminal energy. This is a big challenge for Serious Software Development. It is a misconception to understand IT Security as a compilation of appliances and components like firewalls, IDS or anti-malware. This is not enough! Security must be addressed very early in the development process, latest in the phase of requirement engineering. As a result, a security architecture that is professionally designed, implemented, put in place, enforced, and maintained must be expected. This process comprises a lot of activities: coding principles, security features, threat assessments, testing (and testing and testing) and many more. And, teams should strive for less complexity. I know, it’s easier said than done. But it is nearly impossible to „make a complex system secure“. Upcoming posts will cover this topic in more detail.

Tuesday, May 29, 2007

Will conventional virus scanner still work in the future?

Most of today’s virus scanners are signature based. This means that they need a footprint of the malware in order to detect and remove the malicious code. There is nothing new about it. It is also a matter of fact that the Zoo of malicious code is growing each and every day. Unfortunately, there is no issue with endangered species to determine (unfortunately just in this case talking about computer worms and viruses). This day-by-day increase got impact on the signature repository and the time and load a virus scanner needs to check on a computer. You can check this at home. It takes longer and longer to run a complete scan. What’s the way out? Do we need a separate processor core just for scanning the system? This is probably not the best solution. Anti-malware must be reworked, a new approach is needed. This will lead to a merge of different product types: conventional virus scanner and systems checking on anomalies, flaws and vulnerabilities.

Saturday, May 26, 2007

My Hometown Dresden


Just an impression from May 2007. It was a beautiful evening, two days before I turned the 43.


Why do we need a Software Architecture?

Why do we need a Software Architecture? Pretty old question, right? I have compiled an answer by using a simple example. Here we go, in German again:

Warum benötigen wir Softwarearchitektur?

Die Antwort findet sich wie so oft im realen (nicht virtualisierten IT-) Leben. Jeder der ein Haus bauen möchte, wendet sich zuerst an einen Architekten. Der Architekt ist, neben dem Bauleiter, oft die wichtigste Person über die gesamte Bauzeit hinweg. Warum ist das so? Weil Häuser und Software komplexe Gebilde sind. Weil man Know-How und Erfahrung benötigt, um ein Haus aus unzähligen Komponenten zusammenzusetzen. Weil der Bauherr nicht nur ein funktionales Haus möchte, sondern auch ästhetische Anforderungen und viele andere Wünsche hat, die er vielleicht nicht explizit ausspricht, aber trotzdem voraussetzt. Bei der Übergabe erwartet er ein Haus, das funktional, sicher, robust, haltbar, wartbar und effizient, beispielsweise in Bezug auf Energie, ist. Dazu bedarf es einer Architektur, wie im richtigen IT-Leben. :-)

Tuesday, May 15, 2007

Software Companies in the Media

There was a article about Google and Microsoft in the German Newspaper Welt last week. I have sent a comment which was not published. Here we go (I will translate later):

Leserbrief zu Wachablösung für Microsoft

Leider erfolgt die Darstellung der Firmen Microsoft und Google in den Medien oft sehr einseitig und voreingenommen. Beide Konzerne werden als bedrohlich dargestellt und manchmal regelrecht verteufelt. Dabei wird vollkommen ausgeblendet, welchen Beitrag beide Firmen für eine moderne und vernetzte Welt geleistet haben. Microsoft hat es geschafft, dass Millionen von Menschen auf der Grundlage eines Standards Dokumente austauschen können. Google wiederum erlaubt den sekundenschnellen Zugriff auf Informationen. Damit wurde der Fortschritt der Menschheit ohne Zweifel beschleunigt und neue Chancen für ein globales Wachstum eröffnet, von den vielen neuen Arbeitsplätzen einmal ganz abgesehen. Daran sollte vor allem die EU denken, wenn sie immer wieder neue Prozesse gegen Microsoft (uns sicher auch bald gegen Google) anstrengt, die oft jeder Grundlage entbehren.

Sunday, May 06, 2007

CISSP, Finally ...

... I made it. I passed the exam for CISSP (Certified Information Systems Security Professional) last month. The test has a scope of 250 multiple choice questions (in 6 yours). The title is good for one year.

Sunday, April 22, 2007

Friday Nite Television

There was a film on German's ARTE "Wer hat Angst vor Google?" (Who is afraid of Google?) Friday nite. It was pretty decent stuff. It is amazing how fast this company is growing. It was also fascinating how Google defines CREATIVITY. No wonder that these guys are successful as they are. It was also interesting how the Google guys were fighting to keep their homepage as it ist, without any ads.

Sunday, February 11, 2007

AJAX and Security

This is bad news. AJAX spawns more vulnerability to web applications by increasing and adding attack vectors. This is because of the extensive usage on client side scripting. Typical attack scenarios are imaginable:
- Method Discovery
- Parameter Tampering
- XSS (Cross-Site Scripting)
- XSRF (Cross-Site Request Forgery)

This is not just true for poor coding. Existing frameworks are prone to such security leaks too. And, such attacks don’t demand extensive geek-knowledge. A couple of reasons can be identified. The fact that JavaScript has no inherent security model might be the most important one. The asynchronous model increases the chance to guess and tamper parameters. Request that return JavaScript are especially vulnerable. In general, the increased complexity of client-side scripting makes it harder to avoid un-secure

Distributed Computing

I'm looking for people interested in distributed computing; especially with experience in MPI / OpenMP. I do see a lack of solutions / tools /frameworks to leverage the power of multi-kernel CPU's and multi-processor architecture. More is about to come ...