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.