Coding the Architecture - experience tag

To SQL or not to SQL?

Tue, 21 Jul 2009 10:07:00 GMT

Eric Lai wrote an interesting article for Computerworld entitled No to SQL? Anti-database movement gains steam that highlighted the small but growing trend for not using a traditional relational database for managing data. Nati Shalom's No to SQL? Anti-database movement gains steam - My Take is a good follow-up.

I'm sure that most of us have good experiences of using a relational database in our projects and, despite the pain of sometimes mapping the data into a relational schema, relational databases provide an easy to use known quantity for managing data. With this in mind, you should certainly let your experience guide you but bear in mind that relational databases aren't the answer to every question.

The case study that we use as a basis for the exercises in our software architecture training course is relatively small yet most people decide to use a relational database to store the data without really giving the alternatives a second thought. Most of the time it comes down to experience in that most people are comfortable with using a relational database in their architecture. But there are many viable alternatives; from using flat files and object databases through to in-memory data structures, data grids and the cloud. So while relational databases might be a solution for your particular problem, it's always worth spending a couple of minutes assessing whether they are the *best* solution. Here are some things to think about before deciding on whether to go down the SQL or non-SQL route.

Do you have special non-functional requirements that would be hard to satisfy with a relational database? (e.g. high performance/low latency, massive scalability, etc)
What is the available skillset of the team?
Do you have existing licenses for an RDBMS?
Could an open source RDBMS be appropriate?
Do you need to access legacy systems where the data is already in an RDBMS?
Do you have the hardware available to run an RDBMS?
Do you already have existing backup and archival processes and procedures for relational databases?
What are your management information and reporting requirements (scheduled and ad hoc)? Is it possible to satisfy these with a non-SQL solution?
Do other systems need access to your data via a SQL interface? (a service gateway might be a better approach, but that's another issue)
Do you have data migration requirements from an existing relational database?
Can the data management problem be split up into transactional and non-transactional partitions, maybe using a relational database for only one of them?
Do you really *need* persistence?

Relational databases are established mainstream solutions that are applicable in many cases. Just don't forget that there are other alternatives too.

Experience should guide, not constrain

Wed, 30 Jul 2008 20:08:00 GMT

One of the things that makes an architect is experience, and in many cases an architect has got where they are because of the expertise that they've built up in their chosen technology; be it Java, .NET or whatever. I'm still of the opinion that it's perfectly viable to be an architect with a particular technology focus (e.g. a Java architect) but there is always a danger that everything will start to look like a single technology solution.

In a way, this is inevitable. If your experience is mainly in technology X, then you're going to feel comfortable designing systems in technology X. Of course, this doesn't necessarily mean that technology X is the best solution. An example that I always cite is that most of my background is in building Java systems; from client-server and web apps through to distributed systems and service-oriented architectures. A few years back, Swing would have been my first choice of technology for building a desktop application. Ask me know though, and I'd lean towards a .NET or RIA client, but ultimately it depends on a number of things. In this case, the influencing factors include the skillset of the team, existing vendor relationships, politics, supported desktop platforms, desktop deployment policies, operational/support requirements and so on.

Being open to other technologies is a hard lesson to learn and, as we've seen on the architecture training course, it's natural for people to stick to their tried and tested technology set. As an architect, you should certainly let your experience guide you in making the right decision. Having said that, you shouldn't let it constrain you.

Patterns are about experience...

Tue, 31 Jan 2006 17:02:15 GMT

Why software patterns are important is a good post about why patterns are important within the context of being an architect.

In general term Patterns can help by trying to identify common solutions to recurring problems. The interesting thing of pattern is that they are captured by experience. They aren't designed upfront in a speculative way. They emerge from the field, from real software that works, from real teams.

...

Pattern reading is an important activity for every software architect which hasn't a valuable experience. I think that pattern studying is an important activity in any computer science curricula. Students can learn a lot about software design and architecture without waiting to hurt in the war's field of a software development job.

Essentially, this is saying that while you can't gain real-world experience from reading, you *can* gain insights into what works and what doesn't. This is an important part of an architect's role and helps you make those critical decisions that balance the functional and the non-functional requirements.