It's cool like that!

For the last few days, I have been playing with Ruby and Groovy. I have to say it very exciting to play with these technologies. Like typical Java applications once you figure out how to configure the application, the development of these applications is very straightforward. I don't have have worry about compiling the files, generating a Web Application Archive (WAR), and deploying the WAR file on the servlet container. Ruby and Groovy for most part take care of this issue. From a software architecture perspective, these two technologies promote software best practices by having built in capabilities to design pattern.

The core philosophy is that it saves time by simply customizing a baselined web application rather than build each class, jsp and configuration file. I was amazed when I built a simple prototype in Ruby and Groovy. It is also takes less time to learn the technology because folks learn alot more when they plan with the code rather than reading a O'reilly book or a Recipe book. It's exciting!

The downsize is that it takes alot more time to understand how the code actually works since the inner working have been abstracted out. I also notice that I would use a standardized approach in naming methods, pages, and classes.

To increase my learning, I have been doing Groovy on JetBrains IntelliJ. It's great and it's better than eclipse. Enjoy!

XML Driven Software Architecture

As technologies are evolving from a procedural to object oriented and architectural principals as loose coupled and flexible software is ideal, developers are constantly thinking or taught to think that abstraction is good and brittle code is bad. This idea has also evolved in Information Technology (IT) enterprises where the notion of a service has caught. Since IT enterprises involve more than hard-core java drinking code junkies, services have evolved into business services where services abstract business processes from their supporting IT systems. As Business Processes are changing with respec... WAIT!!! This is a Technie blog entry so lets stay in the realm of software, hardware and whatever makes a java drinking, red-bull drinking, dry cereal snacking technie happy.

As software architects and developers are praising the likes of Gavin King, who developed the Object Relational Mapping (ORM) technology Hibernate, since they developed technology which abstracts developers from knowing how the data is stored in a relational database. ORM technologies allow programmers think in objects rather than normalized relational tables with primary and foreign keys. The wide argument is that programmers won't get bogged down by writing sql queries but they can simply think of their code as objects. The problem with this notion is that sometimes ORM queries can be poorly written.

As I was pondering this issue today, I realized that ORM still couples the software code like Java to the structure of the database. From my experience, when new tables or fields were created in the database, the ORM code has to be modified and this in turn may affect the actual business logic code. This could get painful when new requirements or the Database Administrator (DBA) has provided a new design to optimize the database.

One way to get around this issue to design the business datamodel as a XML Schemas (XSD). After working with XSDs, I believe they do a great job of capturing the object model. After creating the XSD, generate XMLBeans or JAXB classes and code to these classes. The JDBC code or ORM code can be then communicate to the business logic tier via the XML binding classes. This way the XML binding classes provide a layer of abstraction between the data tier and the business logic tier. The problem with this approach is that XSD can be hairy however if you understand XML and XML technologies than this may be the way to go. The other issue is that there could be issues in the generate classes or how you created the XSD. Once again if you are comfortable with XML then may be a way to go since I think it could be better than ORM.

Please let me know if you disagree with me.

Practical Benefits of Architectural Views and Models

I have been assigned to lead a Services Oriented Architecture (SOA) prototype effort for the organization I work for. Since this project involves building a SOA solution with canned data sources (the easy part) and then formulating best practices in SOA governance (the hard part), I have begun to appreciate the skillset of an architect. IT Architecture helps folks, who are in the architect role, to create artifacts which can communicate the core IT system architecture, process architecture, data architecture, etc., etc, to various audience groups. Creating conceptual models and logical models provides a great mechanism to communicate complex or abstract ideas in a straight forward manner. IT Architecture doesn't simply involve drawing pretty pictures in Visio and show-off your Visio skills but it is more than that. It is the ability to take a system design, complex design and simplifying it to a diagram which conveys the necessary details to its appropriate audience. Being an architecture enables you to improve your communication skills, able to adapt and communicate to various audience in appropriate terms in appropriate detail. It is important to know that even when you are simplifying a concept for a technically novice audience, you cannot compromise the underlying physical architecture of a system. The architect has to know the whole design but then he is astute enough to decipher what is needed and what is not needed when the design is communicated to the appropriate audience. Anyway today I can say that I managed to convince key stakeholders in the project on how the system should be designed. This was a big accomplishment in the project. For any aspiring architects, you will miss developing code, you will miss updating your spend plan but in the end you will be responsible for marketing the system, improving the system and most importanly, communicating the system to the appropriate audience.