Software Architecture Cheatsheet (Part 3/3)

In the previous post, I tried to think of the business constraints that intervene in the choices of a software architect. In this one, I’ll take a feww shots at guessing which technologies are important nowadays to build software solutions for these constraints.

I see… I see…

There are so many technologies out there that I will not risk myself in designing some sort of female magazine test like “tell me about your application, I’ll tell you what technologies you should use”. That’s a very exciting part of what I perceive as what is the job of a software architect: finding the right combination of tools and techniques for a specific business context in order to develophigh-quality, high-value and robust software for customers.

That said, there are a few important areas that seem very important to explore or even master in this world, and more specifically in this new economy we’re facing.

Productive dynamic Java

Java is a very mature and popular technology, so much so that many people have predicted its death times and times again. But in my view, it’s very much alive, especially with recent developments that made Java development much more productive. Of course, SpringSource-originated frameworks like Spring and its galaxy have changed the enterprise Java environment for a long time.

But even more recently, inspiration has come from the “casual programmer” side with Ruby on Rails and Python/Django yielding even more interesting developments like Groovy and Grails that combine the flexibility of a dynamic language with the incredible power and richness of the Java platform.

In my opinion, Groovy/Grails are about to rejuvenate enterprise development in an incredible way.

Modular Java

There has been a lot of marketing fuzz a few months ago about something called Service-Oriented Architecture. Unfortunately, although it was based on common sense, marketers and tool vendors completely killed the concept in the egg, but still, some important aspects have emerged and remain limitations of the most popular technology platforms. One of them is the importance of modularity: the ability to change one part of a system without touching anything else, whether it is to adapt them or to restart them.

OSGi (Open Service Gateway initiative) is a standard that has made a remarkable progression on the server side in the past few months, and with its massive adoption by major vendors, it’s definitely going to be something to watch.

Server-agnostic Rich Internet Applications

RIA-enabling technologies compose a very competive landscape: Adobe Flex, Microsoft Silverlight, Sun JavaFX, and even more niche technologies like OpenLaszlo, Curl. And I’m not even considering all those Javascript frameworks and AJAX-generating techniques that I personally don’t see as viable alternatives in an enterprise environment.

My technology of choice is definitely Adobe Flex: it’s open (and it’s even become one of the most impressive examples of Open Source development lately), it’s robust, it’s server-agnostic (it works with Java, .Net, PHP, Python, what have you), it offers desktop integration capabilities, making it possible to cover many of the use cases mentioned above, and it’s very elegant by design. More importantly it was one of the first RIA technologies out there, which makes it both very mature AND very popular.

Native Mobile Development

Mobile development has always been a hobby. Taking useful applications with you is an old fantasy. For a long time, it’s been so poor that it was difficult to turn this hobby of mine into a professional activity. That was until I came in touch with iPhone SDK development, which really blew me away. For the first time we have some great mobile hardware with unique usability capabilities, and we have the software development platform to use those capabilities like never before. And it’s going to be even better with the release of iPhone OS 3.0.

Of course, it’s about to become a very competitive area too, with the release of Palm WebOS, Google Android and Nokia Qt. But for now, the iPhone SDK is by far the most advanced native mobile development option.

What’s my point?

The purpose of this series is double:

1. try to show why software in general, and software architecture in particular are such exciting fields
2. wake up people who tend to have only one single hammer in their toolbox

Now if in addition to that, it can create a debate, then I have a few questions for you guys (and hopefully gals :oP) So, what technologies do you think are important to know in the current and future software world?

Software Architecture Cheatsheet (Part 2/3)

In the previous post in this series, I tried to enumerate the most frequent kinds of applications. The question I’m going to ask myself here is what are the constraints that intervene in choosing the right paradigm and the correponding technologies to implement it.

Environment! Environment! Environment!

Before we start answering that question, let’s just be clear with something. We live in a world where there are plenty of free and Open Source libraries and frameworks and tools of all kinds. It doesn’t mean that free is always good, but at least it’s an option, and if you have a commercial option that can add some value somewhere, then go for it, it’ll be worth it. So I won’t consider tooling cost as a parameter here.

Performance (high computational power and low bandwidth)

Whenever you hear your customer say “I need it to handle several million transactions per second”or “I quickly want to make decisions based on thousands and thousands of records”, you know that you will have to think about performance. There can be several kinds of performance: memory consumption, CPU cycles, disk space, network bandwidth, hardware cost, etc. And all those metrics very often play together, which means that any change to one of these metrics has an impact on all of the others. For instance, it’s very common that you have to increase memory consumption to optimize CPU or disk access (caching).

Another important characteristics of performance is that optimization requires you to dig deeper into low-level details, because most of the performance is lost when abstracting machine constructs to be closer to human users. That’s why optimizing performance requires more work than doing things naively, and it’s very important to weigh the benefits of this work compared to the cost.

Moreover, it’s sometimes tempting to think of performance very early on and to focus on that more than the business value the application is supposed to create. But experience proves that you can quickly end up with very fast systems that don’t do what they are supposed to do because the closer you are to the machine, the harder it is to develop on it or maintain it. That’s why Donald Knuth said:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Distributivity (number and spreading of end-users)

Nowadays, it seems like all applications are meant to be web applications, all the more so with the recent fashion for cloud-based applications that attempt to “webify” traditionally desktop-based apps like word processors, worksheets, and so on.  And there has been so much effort spent in web apps in the past 10 years or so, that everyone knows about the technologies to build them. Yet it’s always important to ask yourself a few questions: will the application be accessible to the general public? Will it be extranet or intranet? How many users are likely to access the application at the same time? Are potential end users ALWAYS online? What would be the impact of the browser crashing in the middle of a session?

Sometimes, having to think about data access concurrency, network bandwidth or security is a useless hurdle that you can avoid just by developing a desktop application.

Automation (launch it regularly and in the background)

What if your application doesn’t need a complex user interface but requires just a few parameters to do its job? What if, on the other hand, it needs to be easily automated and integrated into a batch processing system? When you face such a business context, it’s important to consider the option of a CLI app, because then it can also be easier to integrate with other kernel system apps through scripting.

Whenever you hear your customer say words like “data analysis”, “system check” or “automatic synchronization”, you’d better think twice about your web app idea.

Ergonomics (easy and quick data input and visualization)

At the other hand of the data analysis pipeline, there is data input. And the more data there is to input, the higher the risk of rejection of the application by end users. And since end users generally wait a long time to get theirs hands on the application, this rejection traditionally happens very late in the development process. Combine that with the fact that people who ask for the application are not the ones using it, and the very special mindset of developers and you have all the chance in the world to miss your target and have the project fail before it reaches the finish line.

Of course, technology is not the primary solution to this problem. The first thing is to consider end users, consult them, talk with them, even if the business owner doesn’t think it’s useful. Then of course, methodology goes a long in putting the application into end users hands as soon and often as possible. But as soon as you realize the specificity of what users are expecting, you understand that you need a technology that gives you all the freedom to implement very complex use cases, without forgetting about the conventions and paradigms that people are used to.

Integration (with operating system and external systems)

Web apps have another big drawback in addition to ergonomic limitations, which is desktop integration. This issue comes from the security model of the web. Because it’s so easy to access a web application, because you don’t have anything to install and because the application is directly connected, it also creates a huge opportunity for malicious use. Which is why web apps usually work in what is called a sandbox: network access is limited to the originating domain (unless specified otherwise), no direct access to the file system is allowed, no native API access to things like system tray icons, drag and drop and so on.

And if your application has tom import or export very big files, or notify the user on a regular basis, those limitations can be a killer. There are some technologies now that create some sort of a bridge between a runtime plugin in your browser and a runtime app on your machine, but portability of this bridge across systems and across browsers is sometimes limited.

Productivity (getting things done and adapting fast)

How stable are the business rules you’re asking me to implement? How sure do you know what you expect from this application? If your customer answers “not very” to any of these questions, you might think twice about using this low-level highly-optimized programming language. Because if it takes you weeks to implement any change or new feature, your application might quickly end very far away from the business value is was supposed to create.

Fortunately, with the maturity of web application development, there has been a lot of very interesting developments in the area of development productivity lately. Development tools like integrated development environments certainly go a long way in making developers more productive, but when this concern is dealt with at the programming language level, it’s even better.

Maintenance cost (number and quality of resources)

Whatever technologies you plan to use, you definitely must consider the constraint of resources. There are so many techniques out there that it’s impossible for everyone to know all of them. Some of those technologies are very mature and popular, thus making it easier to find people to maintain and evolve your application on the long term. But the more mature the less innovative they often are. So finding the ideal compromise between the benefits of innovation versus the cost of resources to maintain your application is very important. Thus is might require some insight and technology watch in order to anticipate which of these innovative techniques will grow fast and be there for a long time.

And if you really need one of these innovative technologies that is not very popular yet, then don’t forget to include training costs in your plan. Last but not least, don’t forget to consider company-wide policies: IT architecture departments can create substantial impediments on your way, which might lead you to weigh in the cost of those impediments.

Continuity (robustness and evolutivity)

Beyond people able to maintain it, there is another thing that is very important for the longevity of your application: the intrinsic software quality assets of the technologies that you use. Testability, decoupling, Domain Specific Language support, portability, internationalization support, integration capabilities with other technologies and platforms, extensibility, modularity. All those characteristics can be very important to consider if your application is supposed to stay there for more than 5 years and evolve with the business at hand.

A lot of money is spent and sometimes wasted in reegineering entire applications just to keep up with current technologies or new business constraints, so much so that choosing robust and evolutive techniques can greatly reduce the long term ownership cost of the application.

In the final issue, I’ll risk myself into making some predictions about the technologies that seem very important in order to implement applications with that kind of constraints. But before I do that, do you see other business constraints that might be important to consider before choosing the best tools for the job?

Software Architecture Cheatsheet (Part 1/3)

What I really like about being a software artist is the richness of tools and techniques you have at your disposal. And the more tools you have, the harder it is to use the right ones, the more tempting it is to limit yourself to a few of them. But to me it’s like analogic versus digital DJing: given that your ultimate purpose is to create sounds that make people move, why limit yourself to sync-and-scratch when you can have effects, loops, samples and a virtually unlimited library of tracks?

But I’m sort of missing my point here. Let’s get back to software. I’ve recently come to work on a new project that has been in the works for almost 2 years. For 2 years, wanna-be software developers have tried to solve a very difficult problem with very usual tools. It’s like Maslow said:

When you know how to use a hammer, everything starts to look like a nail.

Well, guess what! Everything is NOT a nail. And I’m gonna try to go over the reasons why in this post.

Software is one big family…

…and each member of the family has its own personality.

The most popular right now is certainly web applications. And by web applications, I mean traditional ones. HTML, CSS, throw is a little bit of Javascript, and maybe generate all of that with some server-side scripting like PHP, Python, JSF or whatever. Heavy load on the server, but very lightweight on the client. The interface is somehow poor because it relies heavily on technologies that were designed for documents gathered in websites, rather than for full-blown applications, with all the interactivity that it implies. Yes, some progress has been made in the past few years with all this AJAX stuff, but bear with me, this all seems like tinkering to me.

The mirror opposite of lightweight clients are certainly fat clients, aka desktop applications. Those applications are based on a composition of graphical widgets the user interacts with, throwing events around and interacting with the operating system. Contrary to their web counterpart, they usually require quite a procedure for deployment and maintenance, because they are physically running on the user’s machine and only check in with the server if they need to. But damn they’re fast.

More recently, a new compromise solution has shown up, offering the best of both worlds: the great ergonomy of desktop clients combined with the ease of deployment and maintenance of web clients. That’s what marketing guys have lovingly called Rich Internet Applications. Now behind this lovely RIA thing, there are a few technologies that make it a lot easier to write rich user interfaces that run within the confines of a web browser. But still, those have limitations compared to their pure desktop brethren: poor integration with the operating system, security constraints all over the place, heavily rely on server-side business code.

Now if Rich Internet Applications are web applications that solve the ergonomy problem, there is of course the other side of the compromise: desktop applications that solve the deployment and maintainability issues. Those are sometimes called smart clients: local database, offline mode, online synchronization, automatic updates, easy one-click installation.

Even though, those seem to fulfill the family picture, there are a few weird cousins out there that are good to be known. Command-Line Interface (CLI) applications have poor to no user interface at all. Their main purpose is to be run on the command-line by some geeky system administrator somewhere, or to be part of batch scripts running automatically every night. Very useful for maintenance apps, and for all long tasks like data analysis or system checks.

And of course there are mobile applications and all kinds of embedded systems. The user interface simply cannot be rich here, because the display is so small, and the computing resources are so limited. Small memory, small keyboard. The iPhone is certainly changing the landscape here, but you still have to manage memory!

Don’t forget extension apps, like SAP modules, CMS plugins, MS Access applications. Those are applications of their own. Usually highly specialized but very fast to develop for simple use cases, to get things done quickly.

Finally, even though, they’re less and less popular, there are still many mainframe applications out there. Now I won’t go into much details here because I’ve never set foot on that ground. But it certainly doesn’t harm to remember that it exists.

Now there certainly are a few other kinds of software applications out there that I didn’t think of, but you get my point. There are a lot of different tools out there, and very different techniques to use those tools in order to create software solutions to very different problems. And what makes those problems so different, you might ask. Well, it’s all about the business context. In the second part of this series, I’ll focus on the characteristics of a business environment can influence the tools you choose to implement the solution to a problem.

But before we get there, do you see other kinds of applications that I forgot to mention?

Hello MooPlan!

logoHave you ever tried to organize a meeting or a gathering of some sort, whether it be for business, a birthday party or something like that? Well, if you have, you have certainly experienced the pain of finding the right moment when everyone is available at the same time. When one is available, another one is not, and vice versa, and then people change their mind. Really painful.

Fortunately for us, there are solutions on the web. One of them, and the one I use all the time, is called Doodle. Basically, what Doodle allows you to do is to set up some sort of a quick poll, saying “I want to organize such event and I propose a few time slots”. When your poll is created, you send an email to all the people you want to invite, with a link to your online poll. Invitees go there, check boxes to say if they are available or not on each slot, and once everyone has answered, you can determine which slot is the best option. All good, right?

Well, this solution is better than nothing, but it still has 2 major shortcomings. First off, it’s not integrated with anything like your mailbox, your address book or your agenda, which means you have to enter all the information manually, and invitees have to check their agenda manually too. Second, it’s on the web, which means that you can only organize meetings or check your availabilities when you are connected. Those shortcomings have a very important consequence: it can take an awful amount of time to get everyone to reply and send the final invitation, which means that the first invitee to answer might not be available anymore by the time your send him the final date… and we’re back where we started.

I use Doodle a lot, for business meetings, for Poker games with friends, and so on, and I’ve seen that happen a lot. And boy it’s frustrating. Then a couple of months ago, I was playing with my iPhone and I thought “Wait a minute! I have my calendar, my emails and my address book in there. Wouldn’t it be nice to integrate all of that to make it easier to set up gatherings?” Guess what! That’s what MooPlan does now!

So let’s see what it does. It’s a simple 3-step process:

  1. The organizer sets up a meeting, gives it a title, a description, invites a few people from his address book and proposes a few time slots. Then he sends all of that to MooPlan which dispatches invitation emails to everyone.
  2. Every invitee gets an email with a link inside. If they are reading the email on an iPhone, they can click a link to install MooPlan application from the App Store, if they have not already done so. If they have, they can just click the other link to open the invitation directly into MooPlan. They click on the slots on which they are available, and they reply.
  3. Back to the organizer, who sees how many people have already replied. And when enough people have, he just chooses a time slot, clicks “Send Final Invitation”, and BOOM! All the invitees get another email with the final date, location, and all the details of the event.

Now I know what you’re thinking. How is that better than Doodle? Well first, it works on your phone, natively, without any weird web interface, so it’s very easy to use, and you can organize meetings and reply to invitations on the go. Second, it’s already integrated with your address book and your emails. Now of course it still misses integration with the most important part: your calendar. Wouldn’t it be awesome if MooPlan could automatically check your availabilities, or create events in your calendar? Sure it would, and the good news is that MooPlan will do just that… once those capabilities are available for iPhone native applications. And with all the fuzz going around concerning the next version of iPhone internal software, good stuff is coming, that’s all I can say for now. This is just a first version.

When is it going to be available? Well, not tomorrow. I’ve just completed the first full cycle, but there are still a few things to fix, and a lot of testing to do. I don’t think I will be adding any new features in this release, even if I have plenty of ideas. Hopefully, I’ll be able to send it to Apple by mid-April. So stay tuned…

MobiMap 1.0-RC2

I just released version 1.0-RC2 of MobiMap library. Amongst the features I’ve added are:

  • better icons for screen controls
  • better support for touch screen devices with a new zoom slider
  • all strings are now internationalized in French and English
  • a help screen with all the active shortcuts when you hit 5 numeric key
  • it is now possible to customize all shortcuts programmatically

More information on the official site.

And if you want to test a demo application using MobiMap component, just point your mobile browser to http://mobimap.epseelon.org/mobimap.jad

We’d love to hear your feedback.

MobiMap First Release Candidate is Out

We needed a reusable mapping component for TagSpot development, and we wanted it to be Open Source so that everyone can reuse it and improve it for the general interest. There was no such library available on the environment we’re working on so… we made it!

And here comes MobiMap. MobiMap is a library that offers a reusable and customizable mapping component for several mobile platforms. Today, we’re releasing the first release candidate for version 1.0 of the JavaME version. We’re still working on porting this library to Windows Mobile and iPhone environments, and we’ll release the final version of all three libraries at the same time. Until then, we need feedback from mobile developers and we need help to improve the library.

The project website is on http://mobimap.epseelon.org
Out support forum is on http://groups.google.com/group/mobimap
Our issue tracker is here: http://bugs.epseelon.org
MobiMap’s Subversion repository is here: http://svn.epseelon.org/mobimap-javame

Special Thanks go to…

First I would like to thank developers of Pyx4Me and Microemulator, thanks to which we could develop this library on the Mac.

I would like to thank Romain Guy, Richard Bair and the whole SwingLabs Team: MobiMap component is heavily inspired from JXMapViewer Swing component.

Special thanks also go to Antoine Jacquet, aka Royale, whose blog article about tile providers really helped me a lot in understanding all the tile APIs.

And last but not least, thanks to the whole TagSpot team for their help and support.

Finally, if you want to see what MobiMap can do on your phone, you can type the following URL on your phone: http://mobimap.epseelon.org/mobimap.jad. Or if you’re just too lazy to type this URL and you know how to use a QRCode, you can use the one on the right.

Be careful though, as MobiMap will download quite a bit of map data over your mobile connection so…

RIA on Your Phone?

I love Apple. I confess I’m a pure fanboy, writing this post on a Macbook Pro I’m very proud of, and I really admire what Steve Jobs has managed to do with this company in just more than 10 years since he returned. But yesterday he did another of these annoying things I really hate: he denigrated a competitor. I mean, when you have great products like Apple does, you don’t need to do that sort of things, and if you do, it obviously means that you are afraid of them.

flexiphone.pngSo when Steve Jobs says that “Flash is not suited for the iPhone“, I don’t hear “Flash will never be available on the iPhone” but “Flash will eventually adapt to the iPhone and when this day comes, we’ll have to deal with it.” The truth is that Adobe has been doing huge things with Flash lately, thanks to Flex. And I’m sure Steve is aware of that. And I see absolutely no coincidence in him spreading that kind of FUD on the same day he’s announcing the iPhone SDK.

For months, Apple has been telling us that we didn’t need any SDK for the iPhone, because we could just write standard AJAX web applications, which is nothing more than a transitional form of rich internet application. Now that the SDK is out (and it really amazes me by the way, but that’s another topic), the web application way of doing things looks really poor in comparison, both more complex to use and less integrated than its heavyweight client alternative. But what if Adobe comes up with a Flash runtime for the iPhone supporting Flash 9 and Tamarin? Then we will have Flex applications on the iPhone, in other words easy-to-develop apps, with no need to go through the App Store. And if Adobe does things right and uses the full power of the iPhone APIs, maybe we could have some special capabilities to integrate multi-touch and other advanced features into our rich mobile applications.

Wouldn’t it be great?!

Now the question is, if Adobe comes with such an adapted Flash support, will Apple accept this alternative and pre-install it on all new iPhones?

I really hope so… But what do you think?

How to make Java suck? Ask Sun!

Whenever I talk about Flex and other Adobe stuff with colleagues and geeks I know, sometimes I get the annoyed answer like “Adobe is evil, it’s proprietary code, there’s a governance issue.” Of course the implicit assumption is that Sun Microsystems does it so much better. Well, let me tell you a story about Sun Microsystems’ tremendous governance.

At this time, I’m trying to put together a prototype for a mobile service of mine, using Java Mobile Edition and several of its optional API’s. One of those API’s is core to my application since it is what I use to connect to my backend server: JSR172, aka Web Services API. When I started this prototype, I knew that using optional API’s is risky, because not all cell phones out there support all of them. But it’s a prototype, I just want to make sure it works on my own super-phone (Nokia N95 8GB), and I’ll try to find a solution later for other phones.

So I ordered my very expensive phone and while I was waiting for it, I started working on my J2ME application. I tested it under Sun’s reference implementation Wireless ToolKit and everything worked just great. Then I downloaded the Nokia toolkit and there I had an issue, something cryptic like “(1) Missing end tag for body or envelope”. I thought it had to be an issue related to the beta version of the toolkit, so when I got my phone, I deployed it there and boom: same error. No way to connect to my backend server! Then I started to get nervous. I left a message on forum.nokia.com, and nobody seems to be able to give me serious options.

So now I’m stuck with an application that works great on Sun’s reference implementation, but nobody uses their implementation on their phones. It could be that Nokia did a bad job reimplementing the specification. But if Sun had done things right, there would be a comprehensive compatibility test that would enforce all the implementations to work the same. Or at least, there would be the option to replace the phone implementation with theirs. But wait, outside of the WTK, the WSA page has not been updated since June 2005! Come on!

No wonder why Google Android and Nokia Qtopia are working on alternatives…

Blown Away!

Sometimes I like to believe that my passion for technology watch gives me this little je ne sais quoi that allows me to determine with a pretty good accuracy whether a given technology is going to be huge or not. Of course sometimes I’m proven wrong, most of the time because something else comes in the way and changes everything. But this time…

If you want to bet on technology horses, here are my tips for the 5 years to come:

  • Rich Internet Applications, and more specifically Flex
  • Model-Driven Architecture, and more specifically AndroMDA
  • Service-Oriented Architectures, and more specifically… nothing in particular, flexible solutions first and foremost (maybe we have to find another name for it before IBM and others make it disappear under tons of marketing crap)
  • Semantic Web, including RDF, OWL & Co.
  • And my special mention today goes to… the one that just reappeared in my top 5: MOBILE SERVICES!

Of course I’m talking about Google’s Android.

Yes, I know, my opinion is biased, I usually love everything Google does, because I can’t help admiring the creativity they are able to generate and the innovation they drive. But hey, I’ve been doing Java ME development on my free time for a few years now, and each time I came back to it, it was like a huge pain: all this fragmentation, impossible to use even the simplest services on my own 6-month old phone… and I don’t even mention this crappy emulator. And now I can’t even develop on my Mac!

Well, guess what! I’ve only been playing with Android for a few minutes, and it has a great development environment (even if I’m still waiting for the IntelliJ integration), a very good-looking emulator, and the API seems really simple to use. And when you read all the industry commitment there is behind it with the Open Handset Alliance, and you start to imagine this could become THE industry standard, with all its openness and non-fragmentation. That’s really exciting!

You know what, that’s what I’ll never like with Sun Microsystems: they have this very annoying tendancy to let go, to release a big clumsy technology, and to rest on the fact that they are the first one on this market. And then they wait. They have done it with J2EE (those who do EJB’s, raise your hands! that’s what I thought…), Spring & Co have created something better, now they’re trying to catch up with JSF and EJB3, but I doubt they will make it. And now it could happen with J2ME: they have neglected mobile platforms for too long, and now they’re going to pay the price. Do I believe that JavaFX Mobile is going to change it? Look, I haven’t seen a single working environment with it yet, but why not. Time will tell!

What about you? What horses would you bet your savings on?