Just got Grand Central!

I finally made it into the Beta of Grand Central! So far it seems really cool. I have 5 invites that I can give away to the first people who comment on this post.

If you haven’t heard about Grand Central, it’s a service that gives you a new phone number that you can use to route calls to any of your other phones. It offers Spam call filtering, a cool online voice mailbox, and click2call features.

One of the coolest features that I’ve seen is being able to seamlessly transfer a call from one phone line to another. So, say that someone calls you while you’re on the road, and you’re just getting home. You answer the call, begin your conversation, walk through your front door, press your * key on your phone and your home phone then rings. You pick up your home phone and continue your conversation on your land-line without using up more of your cell phone minutes!

It appears that most of the features will remain free after the Beta period, except for the click2call features, which will end up charging a per-minute fee.

Who else wants a Grand Central account?

Hacked!

I came to my blog today and saw that my first post showing was May 25, and I though, “Oh snap! I’ve been hacked!” Which is what Phil Burns thought he had experienced earlier this week when his blog’s database rolled back to April.

Then I realized I just hadn’t written anything since then and time has blown by too fast. I guess that means that I’ve been really busy.

My last final

I was about to lay down to go to sleep after an exhausting day, when I realized that there was a final that I hadn’t taken yet. Actually, the final is to write a blog post about what I learned during my Information Architecture class. So, I hope I’m not too late in submitting this last final of my college career. Here’s a wrap-up of what I’ve learned through the course of this semester.

One of the main things that I found unique about this semester is that we used blogging as a platform for discussion and class feedback. I think this was inspired by Paul Allen’s Internet Marketing class which also required class members to write in blogs. I had a great experience blogging in Paul’s class, and I also enjoyed blogging about Information Architecture related topics. I am also excited now to have time to blog more regularly about other topics of interest as well.

Service Oriented Architecture

We started out the semester talking about Service Oriented Architecture (SOA). This was quite exciting for me, because I have been a big fan of web services, which has been one of the major components of the Web 2.0 movement. Previous to the class, I had worked on building small mash-up applications using Flickr, Geocoder.us, and a few other popular web services. I had created a few web services of my own, mostly following the REST style of web service. For this class, I created some SOAP web services using php5’s SOAP extension and Ruby on Rails’ ActionService.

I really think that web services are going to be powering more and more organizations’ enterprise applications. There have been interesting debates in the Ruby on Rails world about the decision that Rails won’t support database stored procedures. From the pro-stored procedure side of things, data architects argue that stored procedures are the way to keep data integrity among all of the accessing applications. David H Hansson, the creator of rails, says the following:

“We took a pretty radical stand: Stored procedures and all things that make your database clever are evil… If you tell a lot of IT shops that, they’ll be majorly offended, because that’s just the way they do things.”

Web services help a company maintain data integrity, because all other functional areas of an organization and their applications use the services to access and manipulate data, rather than accessing the database itself. This gives one more layer of abstraction, and serves a similar purpose to stored procedures. It will be interesting to see if Ruby on Rails’ CRUD-style REST web service library called ActionResource takes off in other areas of web development. For more details on this see the slides(pdf) and video.

Model Driven Architecture

The next topic that we covered in depth was Model Driven Architecture (MDA). My last couple of blog posts covered that topic, so I won’t write a whole lot here. I think MDA has made some major strides in abstracting development to a higher level and could prove promising in the years to come. I think it still has some hurdles to overcome such as designing a system based on user interface needs rather than on the data model that sits behind it. Again, I’m not an expert in MDA, and it’s quite possible that systems exist that more fully address my concerns.

Database Scaling and Optimization

Database design is something that I really pride myself in doing well. I had a good time working as a Teaching Assistant to Dr. Gary Hansen’s database design class a few years ago. Although I felt that I could design a solid database schema to handle complex needs, I wasn’t so confident in my abilities in optimizing queries and scaling a database beyond your standard db box.

This semester gave me the opportunity to bring my skills way up in both optimization and scaling. As a team project, we studied MySQL scaling, and set up a master-slave db server configuration. We studied more complex scaling set ups, and I’m confident that I could implement any of these if I needed to in the future.

Our database optimization project was a fun one. We took complex queries the Mountain Recreation Properties site and optimized them to achieve better performance. After studying up on query optimization, I was able to turn one query that took ~5 seconds to process to under a second just by rewriting it. Then, I took it to under .02 seconds by adding appropriate indexes. I feel much more confident in optimizing any crazy slow-running query to achieve faster results.

Logging

The last concept we covered was logging. As my previous post on Log4J mentioned, I never had put much thought towards logging in any of my applications that I’d built in the past. Now that my eyes have been opened to the world of logging libraries and APIs, I am actually performing more logging tasks.

Once again I’ll plug Ruby on Rails as a superior web platform, as it has logging built right into the framework. Rails uses the standard Ruby Logger class, which is really quite good. Maintainable Software wrote a nice article on logging tips for rails. One of the most interesting things I discovered from that article is that you can perform logging out to a Firebug JavaScript console to help debug your AJAX applications. Pretty cool!

Value Added to My Education

Overall, I feel that my Information Architecture class really added a lot of value to my education. As a systems professional, I need to have a solid background in all of these areas to be a successful systems architect.

I’m now done with all of my finals. And I’ll graduate on Friday! It’s been an awesome last semester!

Good to Great: Flywheel Animation

Jim Collins and his team of researchers set out to find the top turnaround companies that made the leap from good to great. Good to Great is the result of that massive research project. The team started with 1,435 good companies and narrowed them down to 11 that became great, based on their performance over the last 40 years. Jim wrote an article for FastCompany on Good to Great back in September of 2001 which gives a really good overview of the Good to Great principles.

One of my favorite principles that Jim outlines in this book is the principle of the Flywheel. When companies make the leap from good to great, analysts and newspapers go crazy and wonder what big thing that they did to make their company great. The reality is that it took a lot of work and buildup over time.

All of the good to great companies had level 5 leadership, and had done things right. They had the right people on board, and had confronted the brutal facts. They had found the one thing that they could be the best at, that they were passionate about, and that drove their economic engine. In other words they had embraced the hedgehog concept. They had a culture of discipline, and used technology to accelerate their business, although technology wasn’t their driving force. All of these elements together were the constant pushes that they made the flywheel turn.

In his book, Jim describes the flywheel as a “massive metal disk mounted horizontally on an axle, about 30 feet in diameter, 2 feet thick, and weighing about 5,000 pounds.” He says that it’s your job to turn this wheel and get it going as fast and long as possible. Turning this flywheel is like moving a company in a way that it will begin to produce results.

Here is my Flash animation that illustrates this concept:

Click to Play the Animation

 

It’s been almost a year since I did any kind of drawing/animation with Flash, and this took way too long to do, but I think it makes for a good visual of the flywheel concept.

Mentor Graphics EDGE UML Suite

My last few posts have been written on the topic of Model Driven Architecture (MDA). I recently read a white paper(pdf) on Mentor Graphics’ EDGE UML Suite, which is a tool that will take you through the entire MDA software cycle. I must say that I’m beginning to be more convinced of the power of MDA.

The Edge UML Suite is primarily a tool for building software for embedded systems. Mentor Graphics’ MDA tools have been tried and proven in “launch vehicles, life-critical medical systems, fault-tolerant telecom systems, resource-constrained consumer electronics, and distributed, discrete-event HLA simulation systems.” (EDGE UML Suite product page)

Their tools claim to produce code that require smaller footprints than other UML-modeling-to-executable-code tools.

The EDGE UML Suite consists of four tools: the BridgePoint Builder, the BridgePoint Data Access Package, the BridgePoint Debugger, and the BridgePoint Model Compiler. The following diagram displays how these products work together:

Another version of this graphic that is included in the white paper labels the design layer as the platform independent model (PIM), and the translation layer as the platform specific model (PSM). Most embedded systems don’t need much as far as interface design, so there doesn’t seem to be as much interface-related information on this tool like there is for the OlivaNova Model Execution tool.

In the past, I programmed small applications for various barcode-scanning handheld devices. I always prefered working with Rapid Application Development (RAD) tools rather than building the software from scratch in C, or some other lower-level language. RAD tools seemed to limit the application to a small, predefined set of functions, which often forced the creation of custom software. Designing from UML seems to give much greater flexibility in functionality while still allowing for a quick, visual approach to software creation. I would like to someday try out a tool like this.

Examining MDA’s Value Proposition

Model Driven Architecture (MDA) is marketed as the all-encompassing solution for your company’s CIO (http://www.omg.org/mda/executive_overview.htm). It is meant to solve age-old industry problems faced by Systems Analysts and Engineers. It is a means of rapid system design, development and implementation. These systems will be platform independent and will be able to communicate with past, present, and future information systems. It will also offer maximum flexibility for making changes to the system’s model which will then be automatically translated into all parts of the operating system.

As an Information Systems professional, I agree that this would be ideal. Being able to implement a system purely from a higher level design seems to be the utopia for supporting the technical functions of a business. After all, every large-scale system must have a well thought out design including a data model, business processes, use cases, interfaces, etc. The success of an information system relies heavily on the design that precedes the implementation.

MDA seems to be wonderful in theory and I recently saw the OlivaNova Model Execution System in action, which was quite impressive I must say. However, I have my doubts that MDA is the silver bullet that will solve all systems related problems.

One weakness that I see in the MDA approach to software creation is that it seems to remove a lot of the human element of software creation. Although OMG states that one of the core benefits of the MDA is that it focuses on business processes, it seems that “The problem with software development is that there is too much ambiguity in the problem statement and in the design description…” (Alistair Cockburn, Humans and Technology).

Alistair Cockburn, the author of several books on Agile Software Development and Crystal Clear, has written an awesome article titled, “Characterizing people as non-linear, first-order components in software development,” which identifies two main problems with trying to fit people into systems or models.

  • Problem 1. The people on the projects were not interested in learning our system.
  • Problem 2. They were successfully able to ignore us, and were still delivering software, anyway.

Alistair talks about a tool, which resembles MDA characteristics, that was rejected by the technical team. Here is an exerpt:

I shifted over to tool development, working in an ethnocentric fashion as far as possible. I watched the designers of communications protocols, and discussed with them what might be their problems. My colleagues and I decided that, “The problem is that the people are still drawing at the whiteboard. Things will go better if we give them special tools so that they can draw directly into the computer and give them early execution of their designs.”

We spent several years developing an inference engine that would convert time-flow, interaction diagrams into a software architecture and rule system. Many groups were and are working on a similar agenda, e.g., Harel’s executable finite state machines.

We completed the prototype after several years and showed it to our would-be user group, and were shattered to hear them say, “No, thanks, we actually like drawing on the whiteboards. We don’t want to take the time to put the drawings into the computer. Um, may we use the drawing editor portion of your tool suite?” Listening to other tools vendors, we heard the same experiences, usually ending up with, “they use just the drawing editor portion.”

In my experiences with software development, I have found this to be true. Teams prefer to draw on whiteboards, and quickly implement the designs that they have produced. This process works well as the system is broken into small portions and worked on in manageable pieces. Close communication with people who will actually be using the system is vital during this process. End users think of the system in terms of interfaces, rather than the data model that sits behind it to support the interface.

It might be that I don’t have enough experience with MDA to give it a fair judgment. I would be interested in seeing more of it in action. MDA might just be the level of abstraction that brings the technical world to a new level of productivity. I am a big fan of working at the higher-level. That is probably why I enjoy building web software in Ruby, on the Rails framework. Perhaps I will be even more satisfied with the even higher-level development capabilities that MDA wishes to offer.