An architecture for model driven web development (1)
This is the first post in a series that I announced this weekend. In this post, I will introduce the core architecture I use to create my DSL based web development environment. Although not mentioned in the announcement, this post will have multiple editions - hence the (1) in the title - because no architecture is finished and correct the first time. Every time it's revised, a new post on this subject will appear.
Components of the architecture
The key components of the architecture I have in mind are twofold: a run-time environment and a design time environment. The reason for having both environments explicitly as a part of my architecture is based on my interpretation of the IEEE 1471 definition of architecture:
Architecture: the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
I strongly value the bold parts, more than many architects I have met over the past 15 years. I interpret these parts as meaning that the relationship between the components that form a system strongly determine the acceptance and usability of the system by it's intended users, and that an architecture needs to take into account the way the system is going to be designed, realized and extended, including the components used to achieve that.
In the run-time environment we find the typical components of a web application: a web server (e.g. Apache), a database (e.g. MySQL) and a scripting engine (e.g. PHP) or an application server (e.g. JBoss). The design time environment contains tools for scripting (a PHP and JavaScript editor), DSL creation, code generator editing, and code generator execution. Oh, and of course a versioning system like Subversion and a tracking tool like Trac.
With these components in place, we have everything to support a model driven software development process.
A model driven development process
The model driven software development process is based on domain specific languages, and generating code from models defined in those languages.
The process I have in mind here consists of an interative approach, in which three items have to be maintained: a (set of) domain specific modeling language(s) and models created using those languages, a (set of) code generator(s) to generate code from the models, and a generic framework containing the foundation on top of which we generate code. It's no use generating all the code in the framework, since that is not application specific.
Each iteration in my process consists of the following steps:
- Select content of the iteration, in terms of features to realize
- Model the features using the available domain specific modeling language(s), extending it (them) where necessary.
- Generating the code for the new feature, if necessary by prototyping it first and then extending the code generator(s) and/or the framework.
In the experiment described in this series of blog posts, the process is mainly executed by me, myself and I, but past experiences show that this approach works well in cooperation with others, including the domain experts you need to develop an application. I should add here, that my DSL is based on domain terminology from the web application development domain, for which the web itself provides a great dictionary, and the terminology I use when discussing a new web based venture I am starting with two partners. These partners do not speak "W3C", they only speak 'end-user' and 'money maker'.
My selection of components
For my first attempt at building applications based on this architecture, I selected the following components.
- The XAMPP platform, which contains a web server, database and scripting engine:
- Apache 2.1.x web server
- MySQL 5.1.x database
- PHP 5.3.x scripting engine
- CodeIgniter 1.7.x - a Model-View-Controller framework based on PHP, to get a headstart w.r.t. generic stuff
- jQuery UI 1.7.x - a JavaScript library for CSS manipulation and other useful UI things, included in the same vein as CodeIgniter
- Eclipse Galileo PDT, an Eclipse based IDE for PHP and JavaScript development
- MetaEdit+, a graphical DSL creation and modeling environment by MetaCase. This is the only component in my set up that is not Open Source
- Subversion and Trac for version management and issue/progress tracking
That's what we start with...
...and the next post in this series will contain an overview of how these items fit together, and what the first iteration looked like.
Authority inversion kills architecture
Who hasn't heard stories about managers who don't have a clue what their engineers, architects or quality officers are trying to achieve? And who has tried to go over their manager's head to try and fix the problem that way? Out of frustration, or to strenghten their own position, like this lady? I know I did, on a few occasions, and in one case I actually did it - be it without much success.
Earlier this week I was talking to an system architect and friend, working at a high tech electronics company. He's running into something that is related, and that I have experienced in the past as well - something which we agreed could be called 'authority inversion'.
The issue with going over your boss's head is that you contact his boss (substitute manager if you don't like the word boss), to get support for your ideas and have your boss instructed to implement them. Not a very decent thing to do, unless your relation with the person in question is really screwed up. In the case we were discussing, a similar thing happens, but with architects instead of managers. When engineers, regardless of their core discipline like software engineering or electronisch engineering, become more experienced, they eventually get a promotion. They become designers, or architects and are assigned responsibility for technical quality and soundness of systems, or parts of systems, and for guiding other engineers in achieving that.
'Guiding' is the key word here: they have no formal authority, because they are not part of line or project management - in the end the project manager or the development manager is the one to make the final call. This is not necessarily a bad thing, these people have been assigned responsibility for time and budget while the designer or architect was not. However, it can become problematic when the deadline gets nearer and the team contains a few engineers who feel like doing things their own way. Unfortunately, every team of more than 5 people tends to have at least one of those. They do their job, and they are very good at it to a certain level, but they are allergic to making agreements on interface, showing concern for other people's key interests and tend to focus on their key technical interests.
At some point, near the deadline of a project, the architect is confronted with choices made by these people that were not communicated or which they refused to reverse when communication was in place. At that point, the deadline is so close, as well as the end of the budget, that the architect's arguments about long term quality guarantees are overruled for the sake of time-to-market and delivering-on-budget. This is what we agreed to call 'authority inversion': an architect or designer is asked to take responsibility for quality of design, and made a recognised authority in that area. Some of the members on the projects he works on do not go along with that, and in the end get their way in front of the project manager or line manager. 'It works now, and it's too expensive or too late to fix it. If it becomes a problem later on, others will deal with it', is the final remark in a lot of cases.
Painful, for the architect, and painful for software or systems architecture as a discipline. There are still a lot of people who think we have a high tech industry that can sustain itself and it's products by this way of working, who don't believe we need requirements engineering, architecture or test management - but also not agile development or model driven development. As long as we have to deal with authority inversion as described here, we have a long way to go.
Just to make sure: this is not a rant against engineers, or meant to say they don't believe in quality. Every engineer believes in quality, but not all of them see what is important for overall system quality, and that makes them dangerous when combined with ignorant managers.
CodeGeneration 2010
Well, PPL2009 was last week, SPA2010 is closing it's call for proposals, OOPSLA is currently underway and OOP 2010 is in January. So, why not announce Code Generation 2010 right now 
The site is up, and the call for speakers is open. If time allows, I'll submit a proposal to present a comparison of building the same application with MetaEdit+, XText and MPS.
Only drawback is that I have to make the comparison first, hence the 'if time allows'.
Presentation at DSP Valley seminar
On December 19th, I will be presenting at the DSP Valley seminar Embedding quality in your software (click on the link at the main page). The program is quite varied, from testing through process improvement to formal modeling and (mine) non-technical matters you have to deal with.
The TOP Model
Key to my work, and to the translated articles I’m publishing here is the TOP model. I’ll elaborate more on this later, but here’s a short description of the underlying idea of the model.
From experience, we know that human behaviour plays an important role in software engineering – after all, we are still humans creating software. The TOP model ( Technology, Organisation and Process) integrates these observations into a consistent and pragmatic view on the discipline. The delicate balance between three axes of the model determines the success of development projects. All important decisions must be made with the balance between the three axes in mind. The absence of synergy between technology, organisation and process works like sand in an engine.
Chef cook or architect? Cont’d…
I asked Gerrit Muller’s opinion on the previous post – which, by the way, is not yet reflecting my curiousity, I’ll try rephrasing things a bit within the next month or so.
Gerrit’s reaction consisted of two remarks:
First of all, he thinks Gordon Ramsay (like Gerrit himself I guess) is beyond the stage of senior chef/senior architect. He’s grown to become a consultant/trainer/advisor. Still, the parallel is very clear.
Second remark was that this parallel is similar to those that others have come up with (I never had the intention to be original 
). Examples of these are comparisions of system/software architects with movie directors, composers, conductors etc.
Chef cook or architect?
Software and system architects are more than just designer, just follow the Gaudi and Bredemeyer links on this blog’s ‘Interesting links’ section to find out. Architects are supposed to write specifications, discuss requirements, coach people and so on…
Last week, as I was watching chef cook Gordon Ramsay’s show “Ramsay’s Kitchen Nightmares”, I noticed that the same applies to chef cooks – with the difference that real chefs like Gordon have developed their skillset a lot further than today’s software architects. In the show, Gordon visit’s restaurants in trouble. He looks around there and talks to owners and personnel to find out what is wrong. After this, he gives advise on how to improve and returns to check out how things went a month later. As can be seen on the show, from the way he talks to people, and how he sets examples that a chef cook is not only good at preparing food, but also at the following
- making up new items for the menu
- preparing and perfecting them
- training kitchen staff on preparing them
- coaching kitchen and restaurant staff (waiters!) on how to co-operate
- define how money’s going to be made (set prices so that the public is attracted and increase the margin on the wine to make up)
- defining how to decorate the restaurant to create and atmosphere that matches the food
- and so on….
Gerrit Muller indicated that an architect is a 20-headed monster (he started out with 17 heads at first, if I recall), but it seems like a chef has just as many.
Question to those interested: what can we, software and system architects, learn from the professional chefs, whose job description has matured quite a bit longer than ours?
For more info on the chef-consultant, visit Gordon Ramsay’s web site.
Categories
SysML Software engineering Content Management World The architect Progressive Rock Blogging Abstraction Code generation Model Driven Architecture
Recent posts
- Language Workbench Competition: Case is online!!
- Language Workbench Competition
- Trends in model driven development (cont’d)
- Trends in modeldriven software development
- New looks for Consultants United
Twitter...
- Somerset was too far to drive in one day. Changed plans and did crash landing in Forest of Dean. 2 weeks ago
- Left Yorkshire, lunch at Sherwood Forest and then on to Oxford, or Somerset. 2 weeks ago
- @stevekmcc Finland some other time, maybe in 2 years. Canada next year, unless market crashes again. in reply to stevekmcc 2 weeks ago
- More updates...
Powered by Twitter Tools
Recent comments
- Andriy Levytskyy on An architecture for model driven web development (1)
- Tweets die vermelden Language Workbench Competition « New Thoughts -- Topsy.com on Language Workbench Competition
- Jean-Sebastien on Trends in model driven development (cont’d)
- Angelo on Trends in model driven development (cont’d)
- Rafael Chaves on Trends in model driven development (cont’d)