Skip to main content

Posts

When to use a graph database

Interested in graph databases? Here's an article with an example when to use a graph database rather then a traditional relationship database. After studying graph databases I realize that the choice of an RDBMS that I often do isn't necessarily based on the fact that RDBMS is the best choice. RDBMS is such an integral part of my backbone I don't think of anything else. A very good quote from the article is: You wouldn't use only one data structure for every type of data in memory, why would you do that just because you're storing the data? More on the subject: Graph databases on Wikipedia Neo4j Introduction to Graph Databases

The God element

In mid March of 2013 the God particle was confirmed to exist to the joy of many scientists. In software architecture, the God element has been around for years, and in contrast to the particle, the element is fairly easy to spot. The God element 1 is an element with a lot of connections to other objects in the system, the element is in the center of attention and is often called “manager”. The problem with this design is that the manager is responsible for all the functionality, the manager is the entire system and the other objects merely acts as e.g. data providers. Another problem is that it may lead to a complex system that is difficult to maintain, the manager does too much. Performance, reliability and scalability are key quality attributes that are effected by this type of design. The solution is to spread out the responsibilities among the elements. Software Systems Architecture 1 gives a guideline: "if you find more than 50% of your system's respons...

A couple of new books

My pile of books is getting larger. In today's mail was a package with the following books: The process of software architecture, Peter Eeles and Peter Cripps The trusted advisor fieldbook, Charles H. Green and Andrea P. Howe The pyramid principle, Barbara Minto Writing winning business proposals, Richard C. Freed, Joseph D. Romano and Shervin Freed Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin I'm going to start with The pyramid principle, I definitely need to enhance my writing and I hope to get some pointers in writing short, solid and understandable.

Software Systems Architecture - revisited

A few weeks ago I started to read the book Software Systems Architecture by Nick Rozanski and Eoin Woods, see earlier blog post . The authors tries to explain the process of software architecture and which tools to use. The book is divided into a number of parts and the second part describes the (getting your hands dirty) working process very well. The chapters in the second part defines which work tasks need to be executed in order produce a well-motivated architecture. Among the tasks are: Identify the concerns and problems the architecture shall solve? Who are the stakeholders? Who will be affected by the product? Create scenarios in order verify requirements and how different architectural solutions will affect the stakeholders. Find missing requirements. Evaluate the architecture proposal. How to create architectural models to visualize the architecture proposal. Summarizing it all, writing the architectural description (AD). The third part contains a catalog of view...