This was the first day of OMG's technical meeting, here at Costa Rica.
I attended the Architecture-Driven Modernization (ADM) – Case Studies Information Day hosted by William Ulrich and Philip Newcomb.

First of all, William did a great introduction to ADM, that I can summarize as a process to update software system solutions (legacy ones) to newer (modern) languages and architectural best practices.

Now, the actual focus was about synching the business architecture to the IT (technical) architecture. This idea I had talked about in several other places: there is a trend to create IT solutions that require the business architecture to be adjusted to the IT decisions, and not all the way around. And they seem to move independently.

The presentation was good, but, based on the cases that were presented, the whole ideal was not actually implemented as it was described (maybe I missed something). Two cases were about translating the solution from ancient languages to new ones (Modernization of the EuroCAT Air Traffic Management System (EATMS) and Model-driven Reverse Engineering of Cobol-based applications). The other case was a different approach, using a SOA wrap of the legacy modules and building improvements upon it (SOA and BPM enabling an Agile Enterprise Architecture that, btw, didn't mention much of BPM).

So, my questions went around the ideal presentation of using architecture as a driven force to modernization, still the cases were more on language translation (so far no architecture look up). Also, the language translation was achieved using tools that were to automate the process. In this regard, I'm not sure about the capabilities of those tools to pass from a pure procedural language to an object oriented one (I know you can use Java for procedural programming, but to use it as OO requires modeling that cannot be automated). Still the answer Phil gave me was that I made an assertion, not a question, and that my assertion was wrong. I blame my english.

OMG has two standards, KDM (now an standard) and ASMT (in final stages). The first is to model knowledge, used to obtain a model of working solution. The other one is to model language, so I can pass from a written program into ASMT, do refactoring there (language agnostic) and then save using another language. That way I get language modernization (refactoring since there is no functional change). I think that is great.

Still, I was expecting more discussion about architectural visualization of legacy systems, architectural refactoring and evaluation of legacy solutions.

I will read a little bit more and write another post about that.

Will see tomorrow on the SOA and BPM day.\

William Martinez Pomares.

Commenting on Tim Bray’s blog post about the use of Post for REST, I came to a discussion about actually how much RESTFull is an API, and more specifically if it should be RESTFull at all.

You see, many people is trying to get their APIs into the REST world, and some people like Dilip Krishnan believe the reason is to gain "simplicity, discoverability and serendipitous reuse of the solution". Still, as I read through all the comments on how to "imagine" the app so it fits REST, I feel a greater sense of something not right about it.

When creating a solution, you may want to analyze first the functional requirements, and then the quality properties. The ones noted by Dilip are great, but I’m not sure all apps that hit the web every day need to accomplish them. Furthermore, REST is not the only way of getting those attributes! Let’s explain a little what this famous style is so you can understand what I’m saying.

The REpresentational State Transfer style was born as an architectural style to represent/improve the modern web implementation, as Roy Fielding explains in his dissertation. So, REST is an architectural style, and that means it has a set of constrains that the app needs to adopt to obtain the benefits. But that architectural style is not built from scratch. It is built by composing several other well known styles like Client-Cache-Stateless-Server, Layered-Client-Server or Code-On-Demand. Any of those can be used separately and all their pros and cons will be cast upon the solution.

Now, this is a special case where an implementation is taken as a base to develop an architectural style that improves it. Usually, you have a solution to build with a set of requirements, and you look for an style that better fit into the problem. But once you start changing the problem just to adjust to an architectural style, you are actually “Wagging the Dog” there. And it seems to be a contagious syndrome.

So, what does it need to have an APP to be worthy enough to use the style? Well, first

• - the semantics should be the ones of the style.
• - Next, the app should try to solve a similar issue the style is solving, and third,
• - the app’s quality attributes should be the ones the style is promoting.

If some of the three is not true for your app, and you still want to use the style, I may guess you are trying to get the buzzword title instead of the real benefits.

One little clarification at this point: The web is one implementation that follows the style, it is NOT REST itself. What do I mean by that? Creating an app that runs on the web doesn’t make it RESTFull. Using HTTP for your API won’t make it either (I wanted to clarify it since all comments are about HTTP and its semantics and it seems everybody confuses the implementation with the style). You need to read the dissertation to learn all the constrains, but even more important, to learn if the style is for you or not. You may learn HTTP is not a required protocol, but one constructed that meets the constrains. You can build your own! (and make it standard).

William Martinez.

Neal Ford from ThoughtWorks, recently wrote an article that is the first of a series related to architecturing and design called Evolutionary Architecture and Emergent Design. The first article is a revisit to the architecture and design concepts. In it, Neal describes the evolutionary architecture with these lines:

However, just because you can't allow architecture to emerge doesn't mean that it can't evolve. If you have created a flexible architecture and taken care not to create an irreversible decision, you can allow it to evolve over time as new concerns appear.

Let's talk about that idea...

Pages: 1 · 2 · 3

Hello!

Back from a long time. And that is because there is a new baby at home, our first!

Say hello to Juan Pablo, from now on part of my life.
Oh, Fatherhood... that is a great adventure...

William.

This is a quick post to notify all people out there that there seems to be a lot of people confused about the real meaning of the terms in the title. Let’s see:

Ajax is not a graphical technique. Surprised? Well, it never was. I see lots of Ajax frameworks out there providing graphical gadgets/components and people believe Ajax is just a way to mimic desktop look and feel in the browser.

Ajax was born to be a way of having asynchronous calls to the server, that is without the need of a page load for each new data fetch. That data was supposed to be done using XML (now Json is another option), and the call with HTTPRequest object. The data was helpful for lots of things, one of them loading combo boxes on the fly. Of course, the examples were done in UI to show the technique, and later on everybody was confused, thinking Ajax was just a way to make the UI experience richer.

Ah, and there we got Rich Internet Applications. These applications are real richer in user interactivity (think on Gmail). You can create those things using other tools, not necessarily Ajax techniques (yes, Ajax is not a tool nor a framework, but a technique). You can even (at an extreme) have RIA using Javascript and NO AJAX! A simple Flash site can be a RIA with no Ajax. And another Flash site may use Ajax (actionscript also counts) to make things richer.

Lastly, Web 2.0 is not Ajax, nor RIA! Web 2.0 is about people, the web working all the way around. Instead of the site owner posting and all the other mortals reading, web 2.0 says all the other may contribute to the site, create communities, build collective knowledge, be a part of the site! Now, to achieve this, sites can attract people using flashy pages, actual RIAs, and those may use Ajax to implement.

So, when someone says: “Here is the new tool for Web 2.0!” and you read later on it is a RIA tool, and later on that the tools allows to create rich pages using Ajax, you may note that someone does not know what is he talking about.

William Martinez Pomares