Jimmy Z

Today was my final day of graduation ceremonies. I’ve finally completed six years of college and now have both a  BSIS  (Bachelor of Science, Information Systems) and a MISM (Master of Information Systems Management) degree from BYU’s Marriott School of Management.

So what are my plans from here on out? A partner, Brian Corrales, and I have started a business named Apriux. It comes from the Latin root prius which means “ahead of” or “leading.” We will be offering web consulting services including design, development (php and ruby), analytics analysis, and Internet marketing services. We are connected with some of the best design and development professionals in the industry and we are going to have a really exciting first year.

We are currently working with some really good clients and will be helping them to launch their products in the coming months.

If you know anybody that is looking to either establish or grow their presence on the web, please let me know. We’ll gladly work them in as soon as our availability opens back up.

We are also looking for more talented developers to join the team.

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!

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:

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

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.

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.

Model Driven Architecture (MDA) is a standard developed by the Object Management Group (OMG) for separating business logic from application logic. All of the busines logic of your system will be carefully defined by using standard UML modeling and other associated OMG modeling standards which will then be used to generate the technology that actually makes it work.

“OMG’s Model Driven Architecture provides an open, vendor-neutral approach to the challenge of business and technology challenge.” (Object Management Group)

One of the benefits of Model Driven Architecture is that your applications will be built on a standard that will be able to interact with legacy systems and new systems regardless of the platform that it was built on. It uses standards such UML for defining the business model, XML Metadata Interchange (XMI) for exchanging and storing model information, and CORBA for middle-ware interaction between systems (http://www.omg.org/mda/executive_overview.htm). These standards are not tied to any software or hardware platform, thus making it possible for an MDA system to adapt to new hardware and software platforms.

You can think of MDA as USB at a system-level. It provides a standard interface for things to connect and work together. For example, my USB flash drive doesn’t care if it’s being plugged into my Mac or my brother’s PC, nor does the PC care if I’m plugging in a Sandisk drive, or my Ipod Shuffle. Rather, it knows that a device of some sort that has been built to the USB standard will be plugged in and that it will be interacting with that standard. The same goes for MDA, it is a standard for defining domain specific, platform independent systems and how these systems will interact.

A standard MDA configuration consists of three components (http://www.omg.org/mda/faq_mda.htm):

1. A definitive platform-independent base model (PIM).
2. One or more platform-specific models (PSM).
3. Sets of interface definitions.

The PIM defines the business logic and domain model of the system. This may consist of use cases and other specifications that don’t depend on a specific platform.

The PIM is then translated into a PSM which is something that a computer can actually run. It may be translated into C++, .NET, Java, or any other major general purpose language. (http://en.wikipedia.org/wiki/Model-driven_architecture)

The interface definitions can either describe how a human will interact with the system, or how middle-ware interfaces will interact with the system.

Because the application is broken down into these different components or layers, a change can be made at the platform independent model (PMI) and then be translated down into working software that will be able to interface with any system or user. This should save time and money.

OMG states that the three biggest benefits of using MDA include (http://www.omg.org/mda/faq_mda.htm):

1. “… attention focuses first on the application’s business functionality and behavior, allowing stakeholders’ investment to concentrate on the aspects that critically affect core business processes.”
2. “An architecture based on the MDA is always ready to deal with yesterday’s, today’s and tomorrow’s ‘next big thing’ and makes it easier to integrate applications and facilities across middleware boundaries.”
3. “Domain facilities defined in the MDA by OMG’s Domain Task Forces will provide much wider interoperability by always being available on a domain’s preferred platform, and on multiple platforms whenever there is a need.”

So, MDA allows systems developers to focus on business processes, integrate with past, current, and future systems, and operate on any platform. That seems to be its main value proposition.

MDA isn’t a technology, it’s a standard, which means that different vendors will be providing solutions built on this standard. For a list of vendors that are already building tools for the MDA standard, see OMG’s Committed Companies and Their Products.

See OMG’s MDA site for more details.

Java Message Service (JMS) is a Java library that allows you to do Message Oriented Middleware (MOM) in order to facilitate messaging between different parts of a distributed system. This type of messaging can be useful in large enterprise information systems that require systems to communicate in a simple manner.

The JMS provides two models for messaging: a point-to-point queuing model and a publish/subscribe model. In the point-to-point model, the message producer knows where it wants to send the message, and it sends it to the queue which is then taken by the receiver. The publish/subscribe model allows for multiple receivers to subscribe to receive certain messages selected by topic. RSS feeds seem to follow a similar pattern as that of the publish/subscribe model in that new content is published and multiple subscribers to that feed can retrieve the new content.

I’m not an expert by any means in using JMS. I just think that the MOM architecture is just an interesting concept. For more information on JMS, see Wikipedia.