I’m starting to think that I’m wayy too interested in maps and geographical coordinates. Things like Google Maps and GPS just make me want to make something great out of all the information we have lying around and put in a map context. I think this is also the reason behind all the location based services, everyone is trying to see what would work. Most of them are fun experiments, but let’s see what sticks.

Finnish boxy architecture, now on Google Earth.

The one thing that reminds me that we do live in a future foretold by all the great 80′s sci-fi movies is Google Earth on iPhone and especially it’s useless feature where you can change the view by tilting the phone. It serves no purpose whatsoever, but it’s cool and feels like “future”. I think Neal Stephenson’s Snow Crash really showed the vision what Google Maps/Earth ultimately could become (think real-time satellite feeds).

A while back magical elves -generated buildings started appear in selected cities in Google Earth, which was also pretty cool. Unfortunately these magical elves were somewhat sloppy about the finer architectural points of our human buildings so most of them look like boxes – and, well, some of the 60-70′s era concrete buildings are in fact (ugly) boxes.

So, when Google revealed their new Building Maker, I was pretty much hooked. It allows you to easily model buildings out of aerial photography. And if you’re good enough, those models might just end up on Google Earth.

This tool reminded me of Amazon’s Mechanical Turk, which was also interesting in how it allowed to harness the human processing capability to tasks unsuited to computers (or magical elves, who don’t grasp our architectural styles). Some might remember how it was used (unsuccessfully) to search for the remains of Steve Fosset’s plane. Google does have some experience in this fields as well, they did something similar with their Google Image Labeler, which paired random people in a game of labeling images. Unlike Mechanical Turk, Image Labeler was mostly harmless fun and a game to kill time for participants. It is this fun part that I find really important in these things. I think Google accidentally or on purpose have also some fun elements in Building Maker, in addition to it’s crack-like addictiveness level.

The best thing about the Building Maker is that it runs in your browser and is dead simple to use. It’s fun. It’s like a small flash game, but instead of just wasting time you waste time in benefit of a commercial, listed company.

So, now I have 25 models worthy of Google’s acceptance criteria. It’s these accomplishments that keep me coming back to model things. Unfortunately, many models were rejected by Google and that of course isn’t fun. The main reasons for rejections so far have been “Incomplete texturing” and “Floating”. The frustrating thing about this is there’s very little I can do about these two problems. It’s a bit frustrating to notice that Google doesn’t have imagery for all sides of the building after you have started to model a building and short of renting a plane and taking pictures yourself there’s not much you can do. Floating is even more frustrating, because there’s very little hinting you can do to tell the modeling software that the box you’re trying to make should, in fact, be on ground level instead of floating couple of meters in the air.

Yes, if you want, you can import the model from Google’s servers into SketchUp and refine the model there, but that’s both extremely difficult and requires a lot of effort. Not fun, but maybe, just maybe, that refining could get your model listed…

Like

Unlike

(Note : I’ve posted this a while back on my personal blog …. But since then i’ve been working on a more general post on Software Architecture and Company Strategy for TIE, I thought this would also belong here as a good background …)

Service Oriented Architecture is the new mantra to ease integration between heterogeneous systems in the enterprise.

Lately, I have been having questions about this approach and this post comes out from different experiences. One being reading Vincent thoughts on the topic.

The other being this excellent and lively presentation by Jim Webb and Martin “architecture guru” Fowler : SOA without ESB. The last was the presentation from Didier Girard during the excellent Université du SI conference in Paris back in early july. The bottom line of both presentations being : the web works. The Web is resources that are easily accessible.

Using Web Services for different systems integration within the Enterprise should be easy. We should have resources easily searchable and accessible. Hence these questions about how relevant Service Oriented Architecture stands as it is implemented today.

SOA the new J2EE (read bloated) solution ?

Are architecture astronauts taking over again ? Discussing the topic with Vincent it just occured to me that SOA was just like the next EJB around. This type of magical thing which is supposed to help “allowing individuals and businesses to focus on what they do best”. Eventually we end up with only one successful project out of 5.

I remember this serverside symposium back in 2003. (wasn’t there though, I was just reading the coverage). That was a cornerstone : Rod Johnson introduced Spring, Gavin King Hibernate and Bruce Tate presented his Bitter EJB book.

For the first time in Java hostory, J2EE myths were started to be analysed in an objective manner :

J2EE Myths and why they are dangerous :

• There are no simple problems
• Database portability is always required
• It’s ok to defer application server choice
• Distrust relational databases
• J2EE developers always know best
• J2EE allows developers to forget about low-level issues
• Achieve scalability through distributing objects (Stateless SesssionBeans with remote interfaces)
• J2EE = EJB

EJB was also the target :

Bruce looked at one of the classic anti-patterns: the “Golden Hammer”. This is the temptation to use this new tool you’ve acquired to solve every problem. EJB has become the modern “Golden Hammer”. Often, this is because people want to put this relatively new, hot technology on their resume.

Scott Ambler reminded that 65 to 80% of J2EE projects were failure and he contributed to make Agile methodologies popular with his Agile Modeling book.

We know how it ended up : Spring became the new J2EE (over industry standards), Hibernate became the standard for J2EE ORM mapping (again over industry standard JDO), Bruce Tate flew From Java to Ruby, Agile methodologies took off, Floyd Marinescu left java-centric serverside (which he had created) to set up infoq, more hybrid technology wise (Java but also Ruby, Rails, .Net) and topic wise (development, architecture but also agile, SOA, etc …).

SOA Vs Agile

I do like this definition of Agile methodologies by Mike Cottmeyer and V. Lee Henson in their essay The Agile business Analyst :

Agile is focussed on driving towards simplicity versus rather than creating systems that manage complexity

The most successful experience I had with Web Services was with a mere XML-RPC standard : Remote Procedure call in XML format over HTTP. This helped us build very quickly a Web Services Layer around a core of services and have all type of technologies (Ruby, PHP, Python, Java) using these services.

My 2 cents on the success of this solution : XML-RPC standard description is one page long. Compare with SOAP’s which is the SOA industry standard agreed on by all the industry big cats and the de facto protocol used in enterprise applications : 20 pages or so of abstraction to please all stakeholders : a pain in the neck for developers and for Agile development.

Gimme a REST

Back to Didier Girard, Martin Fowler and Jim Webb presentations : the future of SOA will be based on the same receipts that make the web the ubiquitous technology the net quickly became. Web is an infinite set of open resources, and the most appropriate architecture for web services should be based on this paradigm.

Besides, the internet has drastically changed the balance of forces in IT world decision making. As Martin Fowler reports it :

Tim Bray contended that the key decisions on technology are made by the programming community. (…) The reason we have so much bloatware in IT is because IT purchasing decisions are usually made on golf courses by people who have lost meaningful contact with the realities of software development.

My bet : in the same way that open source community naturally adopted standards such as Spring, Hibernate, and, to some further extents, RubyOnRails over bloated industry standards (EJB2, JDO and J2E Web Apps respectively), REST should emerge as the natural SOA standard over SOAP.

REpresentational State Transfer aligns Web Services CRUD possibilities to HTTP CRUD support : GET (Read), POST (Create, Update, Delete), PUT (Update), DELETE (Delete) and bring Web Services back to the web : a set of searchable and accessible resources.

I hope this will help saving Web Services from bloatware and help us aligning technology with the business goal.

1 person likes this post.

Unlike