Anyone who has ever attempted to piece together a complex jigsaw puzzle likely will tell you that they get through the painstaking process by focusing on the big picture — and that the completed image is worth it in the end.
The same could be said of an information architect’s job.
“Information architects are really active at the beginning of the project when we’re talking about what the big pieces [are],” said Brian Begy, managing partner of Chicago Data Solutions, a Web and database consulting firm.
As an example, Begy cited a recent project for Chicago Data Solutions that involved building a Web site capable of selling tickets.
“You go to the Web site, you sign up to go to a show, you punch your credit card number in, and then we need to generate a PDF of your ticket with a bar code on it,” he explained.
The information architect’s role in this case would be to look at the big picture and figure out how such a site would work. For instance, he may need to answer questions such as: What is the expense in terms of processor time to generate the PDF? Who should actually generate the PDF?
“Should it be the Web process request [so that] when the user clicks ‘go,’ the server says, ‘I’m going to respond; hold on for five seconds while I build this PDF’? Or should it be some other process that runs on a separate thread?” Begy said. “[It’s] those kinds of decisions, [as well as]: What is the machinery going to look like on the server side or on the client side?”
Dissecting the Project Into Manageable Bits
An information architect is expected not only to break down a large project or problem into manageable chunks, but also to delegate responsibilities and determine how the work will be performed.
For instance, the company has been working on what Begy described as a “very cool project” for one of its customers: monitoring tanks of industrial food waste.
“When you make ice cream, you apparently get a bunch of nasty stuff you don’t really want — either it’s too sweet or too sour,” he said. “We built a system for [one of our customers] where they plug a monitoring device into the side of a tank that will record the pressure in the tank and e-mail the reading. If you know the pressure, you know the level in the tank, and then you can calculate whether or not a truck needs to be sent out to dump some of the runoff and dispose of it.”
The information architect would in turn be expected to break down this process into steps and determine the technical requirements of each.
“[For example], we’re going to need something that can respond to e-mail, something that can read the e-mail,” Begy said. “We’re going to need something else that can take the e-mail, calculate the data contained in it and convert those pressure numbers into actual gallon readings. We’re going to need something that detects whether or not this thing has reported in six hours — in which case we have a problem — or whether or not it’s about to bubble over the top of the tank, [in which case] a text message needs to be sent to somebody to deal with it.”
The information architect also must determine exactly where the work of each step will be performed.
“[For instance], the e-mail processor is going to be one service; it’s going to run on one server in this location and it’s going to have these responsibilities,” Begy said. “The alert system is going to be this service. It’s going to run on this server, and it’s going to have these responsibilities. The Web application displays this data is going to do this type of work and have these responsibilities.”
To effectively break down and assign responsibilities, it is important for people in this job role to find a balance between working out the nitty-gritty details while keeping the broad overview in mind.
“It’s a lot of delegation; it’s a lot of chopping pieces up and deciding how the work is going to be done by the computer,” Begy said. “You have to actually understand what the responsibilities are going to be, and then you have to understand the capabilities and requirements.”
For example, in the scenario mentioned above, the information architect would need to ask himself: Is it feasible to combine e-mail processing and reading conversion in the same process?
“We had a problem on this application where the processing of the messages was so low that it was overrunning the time between message checks,” Begy said. “When you say, ‘Check every two minutes’ from your messages and it takes three minutes for the processor to check, you’re going to have a problem. So we had to farm that kind of work out to other servers because that’s where [the] bottleneck is.”
In fact, a good portion of an information architect’s time is spent trying to determine where aspects of the project are likely to fail and subsequently coming up with ways to monitor it.
“One of the things an information architect is going to have to do is figure out how to handle failure conditions,” Begy said. “What are the responsibilities for dealing with failure conditions at a very broad level? [An information architect is not responsible for] error handling within the application, but [he will have to determine] what happens if the whole application fails. It’s the big picture.”
Problem Solving Is Key
While the typical first step on the path to becoming an information architect would be an undergraduate degree in computer science, Begy said a few members of his staff have liberal arts degrees and learned programming later on. What’s far more important than academic background, he said, is whether a candidate has good problem-solving skills, which are fundamental for success in this role.
For this reason, Begy sets aside a segment of each interview to test the candidate’s ability to think through a solution.
“We discuss a project and give them a horrible, nasty problem we’ve got and say, ‘OK, go. What’s your architecture solution?’” he said. “Sometimes the candidates with really great resumes just fall apart at that stage because they’re not used to being in charge of solving the problem.”
In some cases, this could be attributed to the fact that the candidate has purely textbook knowledge without any hands-on experience. On the other hand, some candidates pleasantly surprise Begy with insightful solutions.
“Sometimes the candidates with resumes that don’t look very promising will jump up and say, ‘Well, I’d do [XYZ],’ and they often point to really good solutions. And that’s really what I’m more concerned with,” he said. “You can always teach people programming languages; that’s not a big deal. I’m much more concerned with the ability to break problems into manageable chunks.”
Another prerequisite for potential entry-level employees, Begy said, is experience building applications using:
- a lightweight scripting language.
- a heavyweight object-oriented language.
- some knowledge of databases.
- the notion of what patterns are and how they work.
A Viable Career Path?
While the typical skill set for information architects is in demand, some smaller companies may not view the title of information architect as a discrete job role. So while large organizations with giant workflow processes might distinguish between an application architect and an information architect — whose functions are similar — smaller companies usually avoid splitting up responsibilities.
Nonetheless, Begy is certain the future is bright for those hoping to break into the field.
“If I were a student or junior programmer, I’d strongly want to get into this type of [job] because it’s the kind of hands-on work that’s really difficult to commoditize,” he said. A lot of programming is turning into a commodity business due in part to outsourcing.
“You want to be the guy who says, ‘How do we build the broad-level stuff?’” Begy said. “You’ve got to have a tight integration between the requirements, the constraints and all these issues, so I can certainly see why an information architect would be an attractive position to be in.”
– Deanna Hartley, email@example.com