Agile and model driven development
Posted in: Architecture The-architect
Erik Philippus has invited me to address the issue of how model driven development relates to agile development, in his upcoming Masterclass Agile Architecting. That’s going to be interesting and fun!
Posted Jul 4, 08:53 PM by Angelo · Comment
Content Management (5)
Posted in: Content-Management The-architect
Well, it’s been a couple of months and I can only conclude that I never got around to actually completing my comparison of CMS systems. I got side tracked a few times by other activities, and in the end I made a very simple choice. I got rid of Joomla on my company site, because it contained too many features for what I need. Instead, I spent one afternoon and one evening creating a very simple web site based on the CodeIgniter framework, with a backend that allows me to update pages and upload content if necessary. All tailor made, and perfect for my needs.
Check out the front-end results on http://www.delphino-consultancy.nl.
Sorry to those expecting a CMS evaluation, I can only conclude all of them were too bloated for my purposes.
Posted Jun 6, 10:54 PM by Angelo · Comment
Wim Hendriksen reacts...
Posted in: Architecture The-architect
It’s in Dutch, but still fun to read for those who can read that language. A while ago Wim Hendriksen wrote a column in Bits amp; Chips magazine on the absence of beauty and esthetics in Systems Architecture. I responded to that in another column, calling him ‘Wim the Romantic’ – and stating that the industry doesn’t allow us to spend time on these items (no matter how dearly we want to). His response ‘Angelo the classical Realist’ is an invitation from him to start pushing the addition of beauty and esthetics to the list of qualities/-ilities/non-functionals we work with in Architecture. Keep an eye out, cause I will accept the invitation…
Posted Apr 7, 05:05 PM by Angelo ·
On software architecture - a short text
Posted in: Architecture The-architect
Here’s a transcript of an e-mail I sent to one of my students, who asked input for a presentation on the topic ‘Why do we need software architecture’. It may be a no-brainer to some, irrelevant or uninteresting to others, but I feel this is a nice summary to use as a starting point for explaining the need for architecture.
“Hello X,
I’ll start with a short answer, otherwise you end up with a book. Feel free to ask additional questions when necessary.
First of all, we are very capable of building things, including software, without architecture. However, often this means that these things are either reasonably simple in nature. If they are not simple, they can still be build without architecture, but in that case we’re bound to find out they are lacking in quality in certain areas. These quality areas can be for example
- maintainability: it’s hard to extend something that has been build up piece by piece without thinking about structure). Extending such programs is difficult, if possible at all, and subject to lots of trial-and-error excercises
- reliability: software build without a plan is often (not always) build with a focus on functionality. In those cases, error handling, robustness tend to be second class citizens, resulting in unreliable solutions. A good example are so called ‘friendly user’ applications: applications that work only if the user knows what the application expects and sticks to that order. There’s no error handling in case a user makes a mistake there. Quite a few old Unix scripts and command line programs suffer from this problem.
Architecture deals with the structure of a (software) system, in terms of it’s decomposition into elements and the way these elements are connected and co-operate. This structure is, as the examples above show, determined not only by the functionality of the system, but also by so-called -ilities or quality attributes.
In real life, this implies that we need to think about these aspects, which in turn are determined by the needs of the environments in which the system is build, produced and used. Finding out the key needs of those environments, and translating them into quality requirements and a proper design for a (software) system is what is software architecture is about.
The amount of environmental needs introduced by stakeholders from the different environments, the amount of quality aspects they translate into – including functionality – and the infinite solution space makes software development into something complex, and software architecture tries to deal with this complexity.
It should be noted however, that software architecture is a discipline with many faces. Some people go for what the agile community calls ‘BDUF, or Big Design Up Front’ – resulting in large models and big documents. Others go for the opposite, following Scrum and eXtreme Programming to the maximum extend – without much documentation. In both cases, architecture plays a role though, because both approaches take into account the needs of the different evironments the system goes through in it’s life cycle (conception, development, production, use, …).
Best regards,
Angelo“
Technorati Tags: software architecture
Posted Dec 15, 12:29 AM by Angelo · Comment
Things every architect should know
Posted in: Architecture The-architect
Thanks to the people behind the SE News newsletter I came across the announcement of the book 97 Things Every Architect Should Know, to be published by O’Reilly early 2009. The site looks a bit sloppy, it’s a badly formatted Wiki, but if you take your time you can find little gems like the one below.
I’m not sure if this book is going to be more than a bundling of 97 ideas from random people, but the fact that the site will remain even after the book is out will give us a chance to decide.
Anyway – this one is fully in line with what I am teaching at the PDEng programme at the Stan Ackermans Institute in Eindhoven the coming 15 months. Just think about it… These three paragraphs capture a problem that approaches like those of the Agile movement are trying to address, but this is one of the briefest and to the point descriptions of the problem. It makes me wonder about the other 96 items selected for the book.
One of the most attractive temptations on a software development project is to consider it successful if it simply meets the written requirements on time and on budget. When the pressure is on and deadlines are approaching the requirements list makes for an appealing defense against the struggles of a project and its architecture. The problem with this outlook is that it does not take into account the premise of any software project: to make the lives of the users better.
Architects treating the identified requirements as the cumulative to-do list for a project are placing an implicit roadblock to discovering the real needs of the client. They run the risk of choosing an architectural approach that would seem foolish if the requirements were reasoned about to discover the deeper meanings within. By taking this viewpoint the architect places himself aligned with the words of the requirements while rejecting their intent. There is no driving need or desire to discover those intentions since expanding on the requirements means the project will have increased scope to deal with to be “successful”. Meanwhile the client is left with a project that risks being little better off then what they could verbally express.
Instead an architect should consider the current set of discovered requirements as a living list of open discussion points. The relationship between the architect and the client now becomes one of shared discovery instead of trying to see how many requirements can be checked off as complete. Each requirement forms an entry point into a conversation to a deeper understanding of the problem and the boundaries for the set of possible solutions to choose from. By taking the view that a requirement is simply accumulated current knowledge an architect is encouraged to approach each one as if the problem will change or at least might be better understood tomorrow. The architect is driven to produce software that is a joy to use and makes the user’s lives better.
by Christopher Dempsey
This work is licensed under Creative Commons Attribution License 3
Posted Sep 23, 06:52 AM by Angelo · Comment
