Applying "Digital Hub" Concepts to Enterprise Software Design

Editor's note: One of the popular topic requests from the recent Mac DevCenter Survey was for more enterprise computing articles. You'll be happy to read that we have some nice pieces in the works, plus today's article, which is the first one in a series by Adam Behringer. So let's get down to business.

I've had the good fortune to design and build custom enterprise software for a variety of business types and industries. One thing that I have discovered is that there are many common issues and design challenges for this type of software, even in vastly different industries. In this article, I will share an architecture approach that has worked well for most of the projects in which I have participated. In future articles, I will give some practical tutorials for building a complex business system one step at a time.

Defining the Problem

Here are some of the characteristics that these types of business systems seem to have in common.

Many different types of users in disseminated locations: In a business setting, there are many different functions that people perform. For example, an IT professional, researcher, company executive, and customer may all have different tasks and needs, but at some point will all have to work together in a collaborative fashion. To make matters worse (or better), technologies like mobile phones, VPN, Wi-Fi, and video conferencing, offices are spreading these people out geographically.

Changing requirements: Businesses today are all about adapting to changing customer needs and trends. Software systems that do not adapt will die. It does not matter that we, as programmers, would like a nice steady target; it is not going to happen.

Developer/technology changes: In order to make custom software a worthwhile investment for a company, it is going to have to be in use for a while. This means it will probably see changes in the developer team and changes in technology. If you have developed this kind of software for any length of time, you have probably run into "dead-end software" that could not be understood when a certain developer left or could not be adapted to interface with an important new technology.

Business mergers and changes : For the good of your stock options, design software that plays well with others. This is a kind of thing that may not impress your boss, or cause jaws to drop at trade shows, but let's have integrity and foresight, as programmers, to design software that serves the greater good. Part of that integrity is designing software that does not, as much as possible, restrict future business decisions.

An Example

To bring home these points, consider a real-world example (the details have been changed to protect the innocent). Imagine a team of crazy-haired mad scientists working in the basement of a Gothic university building, working on some new models for predicting weather. Their customer is the United States government that gives them the grants.

However, the team doesn't only consist of scientists in the basement creating computerized weather models and making theories, although these men and women give direction to the entire project. There are also rugged, National-Geographic-style scientists with smelly boots and cool accents dispersed all over the globe whose job it is to take accurate weather samples (temperature, wind speed, atmospheric pressure, etc.) and report back to home base with this information.

Also, there are some beeper-wearing system administrators who are responsible for keeping the computers running, performing system upgrades, and backing up the imported weather data. And finally, do not forget that it's easier to get a grant renewal if there is a lot of public interest in your project. Therefore, there are students across the world that are keeping up to date with the progress of the scientists in order to make killer projects for their upcoming science fairs.

Now, pretend that the software currently used to facilitate the scientists' work is "dead-end software" because it was written for an operating system that is no longer being supported by any current hardware. The team has asked you to build them a new software system and they have some neat ideas for expanded features.

Let us review the list of common challenges from the preview section to see if they apply to this situation. Are different types of users in different locations going to use the software? Yes! Are the requirements likely to change? You bet! In fact, those field scientists with the cool accents are already starting to be replaced by automated gadgets that can send in the measurement via satellite. Are the developers and/or technology likely to change? Well, the whole reason you got this job was because the last system could not adapt. You will want to be able to look that crazy-haired scientist in the eye and tell him that this system will not suffer the same fate. Might the business merge or change in some significant way in the future? It might! Maybe NASA will like the work they see and will want to utilize it for predicting weather on Mars. It would be a shame if your software prevented them from doing that.

What's an Appropriate Strategy?

When you first learned to program, what is the first thing you learned to do (besides "Hello World")? For me, it was the concept of segmenting through the use of functions. You know, "Hello World" in a function! I am not sure what your experience was, but it remains a fact that dividing software into components is fundamental to the craft. Object-oriented programming is all about this idea.

Why is segmentation important? There are a lot of answers to that question, but let us focus on flexibility. If your code is well-segmented and you want to improve one aspect, you will be able to do so without bringing the whole system to a standstill.

Traditionally, this code segmentation happens within one script or one compiled application. But what if we want to combine some scripts with some compiled applications that are all written in different languages? What if we like Java for server applications but Cocoa or MS Visual Basic is better for writing client user interfaces? What if we want to integrate some commercial software like Adobe Photoshop into the mix?

Apple has designed a system like this, for consumer digital media devices, that they call the digital hub. The essence of the digital hub is that there is one entity that stores data (Macintosh OS X), and many modules connected to the hub and to each other through the hub. These modules might be an application like iPhoto or may be a device like a camera or an iPod. Even remote applications like the iTunes Music Store can participate in the digital hub. Each module is connected to the hub through an imaginary spoke that represents an agreed-upon standard through which the different components can communicate. Because the hub (the operating system, in this case) has been well-designed and well- defined, new modules can be added or old ones can be updated without having to change the entire system.

This hub-and-spoke architecture works well to solve many business problems, too. The telltale sign that you are working with this type of problem is when you have many users doing many different tasks but based around one set of data. Think of retail sales, for example: cash registers record sales data, business executives use the data to revise marketing plans, production staff use the data to keep inventories at the correct levels, etc. In our weather-prediction example, each group of scientists or students is working with the same weather data, but using it in different ways. If you have used iPhoto with a digital camera, it should not be too hard to draw parallels:

How Do You Accomplish a Hub-and-Spoke Design for Business Systems?

First you need a hub. This is the component that stores data and has flexible ways of sharing it. Usually it will be a server of some sort that contains a database, web server, and an application server. There are many options, but my company, Bee Documents, has had good success using Apple xServes running OpenBase as a database, Apache Web Server, and WebObjects as the application web server. We chose WebObjects because it integrates well with databases, is based on Java, and the price was right. WebObjects also has good support for web services, which is great for creating spokes.

Spokes represent the communication between the hub (server) and of all the client processes and interfaces (modules), such as the administration user interface and the tools for field scientists. It seems that every company is pushing its own type of intra-application protocol, but let me suggest what has worked well for me, which is using XML data sent via HTTP, a web service, or some kind of file transfer. What makes XML so wonderful is that most programming languages support it, and there are easy workarounds for languages that do not.

In our weather example, field scientists could use some type of recording application on their iBooks that could send the data to the hub packaged in an XML format. If there was not an Internet connection immediately available, the scientist could save the data to a file as XML and send it in later.

Modules (or client applications) are the fun part. If you have designed the hub and spokes correctly, a module can be almost anything: perhaps a Perl script that finds trends in data, or a Cocoa application that makes it easy to record newly measured data, or an AppleScript that draws a chart in a graphics program. As long as modules can parse and/or create the XML we are using as a spoke, we can plug them in.

In future articles, I'll walk you through the process of designing and creating each of these types of components. Until then, here are some practical steps you can take to improve your business software savvy.

Practical Recommendations

Learn how to create and parse XML: What programming languages do you know? C, Java, Cocoa, Perl, AppleScript? Learn how to create and parse XML in each of them. Encourage your whole team to do the same. This will help you connect heterogeneous technologies, and will look good on your resume too.

Spend the most design time on the database: Most components of the hub design have only one spoke connecting them to the rest of the system; not so for the hub. The database and server, being central to the design, are connected to many components. If you are not very careful about the revisions you make to the hub, they will probably require changes in every client program. You want to minimize this impact, so spend most of your design budget getting the database and server software right. Hire outside consultants if you need to, because as the hub goes, so will go your entire system.

Next, design a good XML format that is expandable and will work for current and future spokes: You will reduce the amount of work you do, and the amount of code you have to maintain, if you can design a good XML format. This will hold of all the data your system requires and is expandable in order to hold future data. I have found that it is better to design an all-exclusive XML format rather than trying to be streamlined. If you have a bandwidth constraint on a specific spoke (say, cell-phone access to data), you could use XSL to extract a subset of data for that particular application.

Learn more about web services: I know from experience that the literature out there on web services can be confusing and sometimes seems academic. This situation will probably improve as the technology matures. However, web services are really important for custom business software. The effort you spend educating yourself in this area will pay off.

Stay current on open source technology that is available: There is a lot of fine work being done out there; much of it is available for free. If you have designed a good architecture for your software system, you should be able to leverage other people's work in your system. However, if you do not know what's out there, you obviously won't be able to use it. If you are looking for a good place to start, try www.cpan.org and www.apache.org.

Adam Behringer works as the CEO of Bee Documents, which strives to help legal and medical firms efficiently manage their documents.

Return to the Mac DevCenter