As you already know, I'm a great fan of simplicity. I've had my share of failures falling into lots of pits on the battle-field of systems integration. Sometimes I even wonder if there is any benefit of integration at all. The dream is always promising, but in reality we're often disappointed by costs, duration, change inflexibility and complexity in general. Well, IT-life cannot be that easy, can it? Just keeping things simple, not integrating at all? In fact, it can. As I have pointed out often, the software development process should be made simpler by disentangling a couple of things like "Methods, Techniques and Tools" or "Project Execution and Project Control" or "Productivity goals in terms of Costs versus Time and Efficiency versus Effectiveness" and more.
But what about the software (architecture) itself? The last few decades came with lots of beautiful technologies like Windows, Client/Server, Internet, Flash/Flex, Virtualization like Cloud-computing and more. Users got really exited about all these possibilities and for a while, so were the developers. It's always fun working with cool technology, isn't it? Well, as long as you don't have to pay for it, wait for it or change it . Using a 3 or 4-layer model or Service Oriented Architecture already helps a lot but it is not enough. And even, when not implemented properly, it only adds complexity and therefore ruining the benefits in the long term.
Recently I've met some good people from the University of Antwerpen, professors Jan Verelst and Herwich Mannaert. They've explored a simple idea. How to design an application with all components on any level having only one input and one output interface? They've called it: "Normalized Systems". Sounds a bit like SOA, but without the middleware and really deeply into the application itself. Of course it's more than just an idea. They've developed a couple of design principles for it as well and have written a book about it. The benefits are obvious. Simpler design, easier development, less risk with changes, lower maintenance costs, better offshoring and outsourcing possibilities, flexible technology adoption and more. Wow, where have I heard this before? Almost every technology vendor has written these gains in large capitals in their sales collateral .
The fun part is that in a chat with Jan and Herwich, they revealed that after having executed a couple of projects with this theory, they've really proved the promises and even more, a less dependence of fancy tools. Bad news for the technology vendors but apparently their tools proved their worth best in complex environments. Maybe they contributed to the complexity first en delivered tools to cope with it afterwards .
For me "Normalized Systems" is the way forward. It fits beautifully into my ideas of disentanglement of processes and even better, it leaves space for technology innovations without having to start all over again every time.
I guess one of the most common causes of projects getting out of control or ending with disappointing results, is a bad design. I ignore bad management and bad craftsmanship here because they are avoidable . And with a bad design I mean a description of the intended goal which in the end when constructed does not bring a happy client. Usually the number of change requests and rework during the construction gets overwhelming and sometimes the complete process has to start all over again.
One of the solutions coming from the engineering of physical goods like cars, houses, bridges and furniture is (3D) Design Visualization. With CAD system the product is drawn mathematically and the result is an on screen very realistic image. You can look at the product from all sides, even the inside like you walk in a real house or through a new designed neighborhood, and sometimes you can even test it by placing the product into a larger environment like furniture or a car in a windtunnel.
It's not difficult to project this idea to software design and development. In fact, prototyping an application is already a very old idea and practice but the difference in here is the use of specific software to simulate the future application with in contradiction to the habit of creating a "cut down to the bone" application (often smartened up to the real thing in a later stage). Rapid Design Visualization (RDV) is a very good idea to reduce overall costs and risk of dissatisfaction at the expense of some addition time and money spend in the design phase.
But the best example of Design Visualization lately, and not only for prototyping purposes, is 3D-printing. For only about 350 Euro on parts, you can create your own open source 3D-printer, the REPRAP. With this printer you can really produce physical goods of a couple of inches in either side (8'' * 8'' * 5.5'') with colored plastic as raw material, including some parts you'll need to finish the printer. In fact, the ultimate goal of this project is to create a 3D-printer which can print itself .
So hey, you could create your own souvenir-shop with models of the Eiffeltower or the Golden Gate bridge or you might want to create some LEGO parts not even on the market . By-the-way, if you don't want to have the hassle of building the printer yourself, you can always buy a semi-professional one for a reasonable price. Nevertheless, the REPRAP is a good start and a great promise. Imagine the possibilities of being able to print not only in plastic but in metals and ceramics as well. You could print your own mobile phone including all the electronics !.
Well, it will take a while to get there but not that long. I predict that in a few years a lot of people have their own 3D-printer. In the first few years i guess you can better run to the shop to buy the goods cheaper, faster and better but that will change rapidly. And hey, who wants stuff everybody already has anyway ?
"Think big, act small, fail fast; learn rapidly" is the famous pitch out of the book "Lean Software Development of Mary and Tom Poppendieck (2003). Very often quoted and more often misunderstood or badly implemented. Lean software development is often embraced as methods (SCRUM, XP, SMART, DSDM, OPEN-UP, IAD, etc.) to avoid the traditional "hard work" to properly design and document the solution before building it but instead "learn on the fly".
Well, one of its valuable characteristics of Lean is indeed the qualitative growth of the team and their work due to advancing insight by test software early and implement it fast. However, that does not mean "fire at will" with some ideas originating from the latest technology.
Some people have not only some good ideas but can also bring these into practice successfully. Hence, they are always surrounded by a small group of enthusiastic followers (hey, where have I heard this before? ).
In software engineering this is not any different. Usually an experienced professional continuously gathers all his best practices and lessons learned and takes a slightly different approach for a new project every time in an attempt to avoid glitches encountered in the previous ones. Most of the time, these changes will focus on a certain aspect in software engineering.
For example, if in such an environment user-contacts appears to be difficult, the change will be around techniques to get users more involved like in agile methods. If the circumstances have made data migration more than a usual challenge, the new approach will be more strongly based on information modeling. If the technology is new and different, the software architecture might be enriched with some new elements. If a project is based mainly on of-the-shelf components, a more package-based approach will be necessary. Or new “priorities” in business or technology like Business Intelligence, Mobile Apps, and Offshore or Service Orientation ask for distinction, and so forth.
With all the App-Stores popping up like mushrooms in the dark, programming seems to have become pretty cool again today. With a staggering 140.000 apps in the Apple App-Store, already way over 10.000 apps in the Android Market and even Microsoft's Marketplace for Mobile is shifting gears and approved over 1,000 apps in just a few months. That a lot of apps do not have that accompanying amazing download rate, is irrelevant. The promise of getting famous or rich with the help of low threshold platforms like the App-Stores is there. So, those of you who didn't write an app for one of the stores yet, shame on you!
With this revival of software engineering maybe it is time to think about what software engineering looks like in about a decade or so. Just extrapolating what we are already doing is not enough. For a start, I simply assume that all infrastructure, application package, and bespoke software engineering converge into one single profession. Make, buy, re-use, free-use, and generate will melt into one pot of components. On top of that, business and technology knowledge will merge as well. So the average experienced solution architect (?) will become an octopus with tentacles in all areas. Only juniors will have the privilege to specialize on their way to the top of their careers.
Productivity 
As you already know, I'm a great fan of simplicity. I've had my share of failures falling into lots of pits on the battle-field of systems integration. Sometimes I even wonder if there is any benefit of integration at all. The dream is always promising, but in reality we're often disappointed by costs, duration, change inflexibility and complexity in general. Well, IT-life cannot be that easy, can it? Just keeping things simple, not integrating at all? In fact, it can. As I have pointed out often, the software development process should be made simpler by disentangling a couple of things like "Methods, Techniques and Tools" or "Project Execution and Project Control" or "Productivity goals in terms of Costs versus Time and Efficiency versus Effectiveness" and more.
. Using a 3 or 4-layer model or Service Oriented Architecture already helps a lot but it is not enough. And even, when not implemented properly, it only adds complexity and therefore ruining the benefits in the long term. 
.
. 
. 
But the best example of Design Visualization lately, and not only for prototyping purposes, is 3D-printing. For only about 350 Euro on parts, you can create your own open source 3D-printer, the REPRAP. With this printer you can really produce physical goods of a couple of inches in either side (8'' * 8'' * 5.5'') with colored plastic as raw material, including some parts you'll need to finish the printer. In fact, the ultimate goal of this project is to create a 3D-printer which can print itself 
. By-the-way, if you don't want to have the hassle of building the printer yourself, you can always buy a semi-professional one for a reasonable price. Nevertheless, the REPRAP is a good start and a great promise. Imagine the possibilities of being able to print not only in plastic but in metals and ceramics as well. You could print your own mobile phone including all the electronics 
!. 
?
.
"Think big, act small, fail fast; learn rapidly" is the famous pitch out of the book "Lean Software Development of Mary and Tom Poppendieck (2003). Very often quoted and more often misunderstood or badly implemented. Lean software development is often embraced as methods (SCRUM, XP, SMART, DSDM, OPEN-UP, IAD, etc.) to avoid the traditional "hard work" to properly design and document the solution before building it but instead "learn on the fly".
Some people have not only some good ideas but can also bring these into practice successfully. Hence, they are always surrounded by a small group of enthusiastic followers (hey, where have I heard this before? 
With all the App-Stores popping up like mushrooms in the dark, programming seems to have become pretty cool again today. With a staggering 140.000 apps in the Apple App-Store, already way over 10.000 apps in the Android Market and even Microsoft's Marketplace for Mobile is shifting gears and approved over 1,000 apps in just a few months. That a lot of apps do not have that accompanying amazing download rate, is irrelevant. The promise of getting famous or rich with the help of low threshold platforms like the App-Stores is there. So, those of you who didn't write an app for one of the stores yet, shame on you! 
